[Css-csts] Simpler modifications/derivations of Cyclic Report for MD-CSTS

[John Pietras]

CSTSWG colleagues ---

 

Our telecon this coming Friday is to be focused on the Monitored Data
CSTS (MD-CSTS). This note addresses a controversial proposal that I made
for the MD-CSTS, and offers in its place two simpler proposals which I
believe will serve the purpose of that previous proposal, but with
(hopefully) little or no controversy. 

 

In July, I sent out an email ("Monitored Data CSTS may not be able to
directly adopt Framework procedures") in which I reported that I was
having difficulty making an approach that I had identified in the Berlin
meeting fit with the Framework procedures. To briefly summarize that
approach, instead of having the user of the Monitored Data CSTS
(MD-CSTS) subscribe to each instance of a monitored parameter (e.g.,
"S-Band return carrier frequency", "X-Band return carrier frequency) in
the START operation of the Cyclic Report procedure, the user would
merely have to subscribe to the type of the monitored parameter and the
service would subsequently report all instances (e.g., if S-band and
X-Band links are operating concurrently, then a subscription to "return
carrier frequency" would result in two parameters being cyclically
reported: "S-Band:return carrier frequency" and X-Band:return carrier
frequency"). I will not review here why the use of the Framework's
Cyclic Report procedure without derivation was problematic, or how my
proposal resolved those problems.

 

Martin responded that he believed that the approach that I was proposing
was more complicated than it needed to be, and Yves expressed similar
concerns when I briefly talked with him about it.

 

With this feedback in mind, I have tried to come up with alternate
approaches that deviate less from the FW's procedures but still solve
the concerns that led to the proposed modifications in the first place.
I have come up with two such proposals. I could incorporate these
proposals as (MD-CSTS) service-specific derivations of the Cyclic Report
procedure (and similar derivations of the Notification procedure), but I
believe that they have a more-general usefulness and am therefore
proposing them as modifications of the Cyclic Report and Notification FW
procedures. 

The first proposal is to add an option (either as a managed parameter or
a parameter of the START invocation) to select the qualifiers that are
to be reported by the service instance: 'valid', 'unavailable',
'undefined', or 'error'. Any parameter values that are tagged with
qualifiers that are not selected for the service instances are simply
not included in the report. There is precedent for this in the SLE RAF
service, which allows the user to select whether all frames, good frames
only, or bad frames only are to be transferred. (RAF, by the way,
supports this selection via the START operation). 

The benefit of this proposal is most clearly illustrated by the case
where a mission includes all possible monitored parameters for all
possible service configurations in the default parameter list, where any
one executing configuration might contain only a small subset of the
total set of monitored parameters. In accordance with the current
(CSTSFW R-0.19) version of the Cyclic Report procedure, such an
all-inclusive default list would result in 'unavailable' reports for the
parameters that are not active for that particular configuration. In
effect, the amount of monitored data being reported would always be the
maximum possible, even though the amount of useful data might only be a
small fraction of that.

 

The second proposal is to generalize the subscription mechanism in the
START operation. In the current (CSTSFW R-0.19) Cyclic Report procedure,
the parameters to be reported can be subscribed to in the START
invocation in one of 3 ways:

- as a list of individual parameter names;

- as the name of a single predefined parameter list; or

- a predefined default list of parameters (designated in the START
invocation by leaving the list-of-parameters parameter empty (null).

 

I propose that the subscription list be able to include any combination
of zero or more individual parameter names and zero or more predefined
parameter list names. Supporting multiple parameter list names (instead
of the current single one for each subscription) allows a user to have
several "canned" parameter list names for combinations of monitored
parameters that correspond to the building blocks of a mission's service
configurations. Allowing a mix of parameter names and lists names in a
single subscription allows the user to subscribe to infrequently-used
parameters in addition to one or more standard sets of monitored
parameters. I believe that adding this generality will not significantly
increase the complexity of implementation. 

 

a)     Having discussed these proposed modifications with Tim Ray and
Erik Barkley, I believe that these two modifications to the current
Cyclic Report procedure can satisfy the great majority of situations
that NASA missions will face in the use of the MD-CSTS. I look forward
to discussing these proposals on Friday.

 

Best regards,

John

 

 

John Pietras

GST, Inc. 

7855 Walker Drive, Suite 200

Greenbelt, MD 20770

240-542-1155

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20090831/4ac8c4df/attachment.html