[Css-csts] Monitored Data CSTS v0.6 White Book on CWE

[John Pietras]

CSTSWG colleagues:

I have uploaded the next draft of the Monitored Data CSTS White Book
(MonitoredDataCSTS_W-0.06clean.zip) to the CCSDS Collaborative Work
Environment (CWE) > Cross Support Services Area (CSS) > Documents >
CSS-CSTS > CWE Private > Future Services using Toolkit folder at the URL
http://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/Future%20Services%2
0using%20Toolkit/MonitoredDataCSTS_W-0.06clean.zip

Note - the URL http://tinyurl.com/63k2bs points to the same document.

This version re-includes the Notification and Information Query
procedures as optional procedures. This draft version also includes an
approach for supporting the reporting of monitored parameter values and
notifiable events when different numbers of instances may be available
on a per-Service Package basis. The following paragraphs describe the
issue that underlies this approach.

To summarize the MD-CSTS:
1. The Complex Management (CM) function of a TT&C service provider
"publishes" the list of monitored parameters that are available for
periodic reporting. The list nominally includes the list of standard
parameters that are to be developed as part of the MD-CSTS
specification.

2. As part of the Service Agreement, the Mission and the Complex
establish a subset of the published parameters that are designated as
the default set.

3. In the process of starting an MD_CSTS service instance, the user of
the MD-CSTS service instance subscribes to a subset of the published
list of parameters. Alternatively, if the user does not explicitly list
the names of parameters at the start of the service instance, the
default list is assumed.

4. The service instance then delivers the values of the subscribed
parameters at the specified frequency, until the user stops the service
instance. If a subscribed parameter happens to not have a value at any
sampling period, that parameter will still be reported which a "value
not available" value.

The issues that I am concerned about are how to deal with multiple
instances of the same monitored parameter type, and how should those
parameters be named. For example, some missions may operate multiple
space links simultaneously (e.g., X-band and S-band). It would be
ambiguous to simply report the value of a parameter simply named
"demodulator lock status" when both X- and S-bands are operating
concurrently. 

Candidate Approach A: A brute-force approach would be to publish, for
each Service Agreement, names for all possible combinations: e.g., for
the above example, there would be separate "X-band demodulator lock
status" and "S-band demodulator lock status" published parameter names.
I see two problems with this approach:
- First, it may be hard to determine a priori the proper set of name
qualifiers for all possible missions, which is what would have to be
done if we wish to develop a standard set of monitored parameter names.
Would band qualifiers be sufficient? 
- Second, it makes the defaulting feature difficult to use effectively
for missions that use different combinations of carriers. If the default
set names parameters from all possible carriers, then there will be a
lot of "value not available" values being reported when all carriers are
*not* being used in a particular Service Package.

Candidate Approach B: A variation of approach A would be to have the
subscription be to all instances of the same type of monitored
parameter. Thus, instead of subscription to "X-band demodulator lock
status" and "S-band demodulator lock status", the user would be to
"demodulator lock status", and whatever monitored parameters of that
type that are active for that Service Package would be reported (but no
"value not available" values would be reported for carriers that are not
in the Service Package. To continue the previous example, If both X and
S band return links are active in a Service Package, a subscription to
"demodulator lock status" would result in "X-band demodulator lock
status" and "S-band demodulator lock status" being reported, but if only
the S-Band return link is active in the Service Package, only "S-band
demodulator lock status" would be reported (with nothing reported for
the X-band demodulator). 

Approach B both simplifies the number of parameters that need to be
subscribed to, and minimizes the amount of "not available" values being
reported back. However, it still does not address how the
fully-qualified names should be defined.

Candidate Approach C: This approach uses the abbreviate subscription
aspect of approach B, but qualifies those names on the basis of names
used in the Service Package.

Service Management has adopted the notion of "space link carrier
profiles" by which pre-packaged sets of configuration parameter values
can be defined and used by simply referring to the identifiers of those
profiles in Service Packages. The MD-CSTS could qualify the monitored
parameter names with the ID of the carrier profile that is being applied
to the link that is generating that monitored parameter value. For
example, if "Return X Config 1" is the name of the configuration profile
that is being applied to the X-band return link in a given Service
Package, then the reported value "demodulator lock status [Return X
Config 1]".

This approach provides a way to avoid the issue of defining a
globally-applicable set of qualifiers. But it may be undesirable in that
it requires implementations to map multiple configuration profile IDs to
parameters. 

Candidate Approach D: This is a variation on approach C. Instead of the
carrier *profile* identifier being used, a "link ID" would be used
instead. The difference between the two is that whereas there can be any
number of configuration *profiles* for a single link carrier (e.g.,
"Return X Config 1", "Return X Config 2", etc.] that can change over
time, the number of RF links (carriers) themselves is constrained by the
design of the spacecraft (e.g., one X-Band return link).

The set of link IDs could be established as part of the Service
Agreement. The Service Agreement currently contains a set of "Space Link
Carrier Agreement" data sets, each of which specifies an envelope of
allowed values for space link carrier profiles. Each space link carrier
profile references the Space Link Carrier Agreement with which it
complies. If we add a "link ID" parameter to each Space Link Carrier
Agreement in the Service Agreement, then the relationship can be
established between the carriers instantiated in any Service Package and
the monitored parameter names that are returned by the MD-CSTS. To
continue the on-going example, assume:
- The Service Agreement has a Space Link Carrier Agreement called
"Return X-Band A", with a Link ID parameter value of "Return X-Band
Link"
[NOTE - There may be more than one Space Link Carrier Agreement for the
same link. This allows Complex-specific constraints on carrier
configurations to be documented in the Service Agreement and enforced.]
- A Space Link Carrier Profile named "Return X Config 1" references
return X-Band-A.
- A Service Package is established that instantiates the carrier profile
"Return X Config 1".
- When the Service Package executes, the MD-CSTS instance is started
with a subscription to "demodulator lock status" (essentially a group
name, not an individual parameter).
- The MD-CSTS then periodically reports "demodulator lock status [Return
X-Band Link]".

The advantage to Approach D (over C) is that the Link IDs can be
statically determined and not tied to carrier profiles per se. A given
TT&C network could mandate the Link IDs used by all user missions so
that the equipment emitting the monitored data would always be
configured to include the same link ID.

My preference is for Approach D. I had a chance to discuss this with
Michael Stoloff, and he agrees, at least in principle. I have therefore
begun to incorporate this approach into the MD-CSTS specification.
However, given time and resource constraints, I have not been able to
completely develop the material for the version (0.6) that has just been
posted. Nevertheless, I wanted to put these ideas out for the members of
the CSTSWG to begin considering before the Berlin meeting.

One issue that I am still struggling with is whether this approach can
be completely defined in the specification of the production that feeds
the data to instances of the MD-CSTS, or whether the service procedures
themselves need to be modified through derivation to support this
approach. The v0.6 White Book attempts to treat the approach as purely a
production concern. This is something that we should discuss in Berlin.

Best regards,
John


John Pietras
Global Science & Technology, Inc. (GST)
7855 Walker Drive
Suite 200
Greenbelt, Maryland, USA
20770-3239
Direct:   +1-240-542-1155
GST Main: +1-301-474-9696
Fax:      +1-301-474-5970