[Css-csts] Monitored Data CSTS may not be able to directly
adoptFramwwork procedures
Martin Götzelmann
martin.goetzelmann at vega.de
Sun Jul 26 13:07:05 EDT 2009
Dear John,
As far as I can see, the problem you are describing originates from the concept that the use should request monitoring of a parameter "type" and the provider should respond by transmitting the values of all instances of that "type".
I tried to recover the status of the WG discussion of this approach from various minutes, but with little success - this is what I believe to remember:
- You have given an initial presentation on definition of parameters Berlin addressing several options
- We had a very brief initial discussion on a Teleconference in March in which the topic was essentially postponed to the Colorado Springs Meeting
- We had a discussion in Colorado Springs but the only decision to this end was that the parameters / the approach to definition of the parameters should be specified in a separate white paper (see Action A7).
As far as I can see from the minutes (and remember) the WG did not seriously address the proposed approach, maybe hoping the problem would go away if the defintion of the parameters would be separated from the specification of the service. Obviously the issue did not go away and needs to be addressed.
I would therefore suggest that the WG explicitlly addresses the basic approach of requesting "parameter types" before discussing the implications on the service specification. I have not been aware of a teleconference on 11th August, but if we have one, I think every Agency should try to establsih a position by then, although I recognise this could be difficult due to the holiday season. Maybe it would be useful if you could very briefly re-state the justification for this proposal. I recognise that you have provided this already in presentations and technical notes, but as these provided lots of other material as well the essential implication for the service might not have become clear to everybody.
My inital personal opinion is the following:
I beleive that I understand the motivation for the proposal and I can see some value in being able to define "generic" sets of monitoring data that are independent of a specific configuration used for a specific mission. But I do have doubts whether the approach is really useful in practice.
I would expect that a user side application needs to know in detail what values will be transmitted by the provider because it needs to process them - at least present them to the operation in some way (typically in fixed tables). I think the situation might be even more complex, if a "monitoring session" extends over more than one "space link session" because this might imply that the configuration changes and consequently the provider would suddenly send a different set of values.
I futher feel that the user side application will generally have to be aware of the configuration, i.e. it will have to know whether there is in only an S-Band receiver or an S-Band and X-Band receiver. If it does, it may as well request the individual parameters it is interested in.
I feel we should maybe also consider other ways of specifying monitored parameter tables in a generic manenr. For instance, one could imagine specifying a "table template" in generic terms (i.e. specifying parameter "types") and then identifying a combination of "template name" and "functional resource name" in the START operation. E.g. one could have a table called "ReceiverChain" and the request "Xband.ReceiverChain". The user would then be able to request monitoring ofeach of these tables in one stream (procedure), which he could stwitch on and off as convenient.
I recognise that this would not work for the "default table". However, my understanding of the "default table" is that it was supposed to support the very simple case, in which both sides agree "somehow" what is transmitted and everything is fixed. If that is true we should not really not care how the contents of the data transmitted by the provider are determined.
Kind Regards,
Martin
________________________________
From: css-csts-bounces at mailman.ccsds.org on behalf of John Pietras
Sent: Fri 24/07/2009 10:19 PM
To: css-csts at mailman.ccsds.org
Cc: Muhammad Rabi
Subject: [Css-csts] Monitored Data CSTS may not be able to directly adoptFramwwork procedures
CSTSWG colleagues ---
Yesterday I sent you an email listing some additional review comments on the CSTS Framework (CSTSFW) R-0.19 version. As I mentioned in that note, those comments were the result of my re-looking at the CSTSFW in the context of the monitored data CSTS (MD-CSTS). Those comments were general to the CSTSFW.
In addition to those general comments, I have additional comments that are specific to its use in the MD-CSTS). In summary, I don't think that it is possible to build the MD-CSTS through direct adoption of CSTS procedures as they are currently defined. I've come up with a refinement-based approach that I plan to use in defining the MD-CSTS, which I will describe shortly in this note. I've also identified an even better approach, which would involve a minor modification to the CSTSFW. I will describe this modification at the end of this note.
Before describing the refinements that I plan to use in the MD-CSTS specification, let me summarize the facts that lead to such a refinement being necessary:
A. Information Query and Cyclic Report procedures
- As currently defined, the Information Query and Cyclic Report procedures both work on the model in which (a) the user subscribes to a specific list of parameters and (b) the procedure generates a value for each of the subscribed parameters. The parameter values are of simple types (e.g., integer, real, character string). For reach parameter named in the list, the provider returns the value of the named parameter, reports that the parameter is not currently available, or reports that the current value is invalid.
- For the Monitored Data service, the user will subscribe to specific sets of parameters for the Cyclic Report and Information Query procedures, but those parameter names are really type (or group) names: each represents a collection of parameter values. For example, the subscribed parameter name may be "rcvrSignalStrength", but if two receivers are active at the time (e.g., X- and S-band), _two_ values will be returned, one for each receiver. This violates the one-to-one model that is inherent in the Framework.
B. Notification procedure
- In the current CSTSFW Notification procedure, the user subscribes to a specific list of events and the procedure generates an event notification whenever one of those subscribed events occurs.
- For the Notification procedure of the MD-CSTS, the user will also subscribe to a specific list of events and the procedure will still generate an event notification whenever one of those subscribed events occurs. However, those names will be different: in the START operation, the names will be type or group names, whereas the event notifications will have to use the names of the specific events. For example, the user may subscribe to the 'carrier modulation unlocked' notification, but would receive event notifications whose parameter names also identify the specific carrier, e.g., "S-Band:carrier modulation unlocked"
I have considered several schemes for deriving Information Query, Cyclic Report, and Notification procedures to accommodate these differences. The one that I have settled on (at least until someone suggests something better) is a refinement approach. The other approaches that I considered all required modification of the behaviors of the procedures which could "break" standard library code written for those CSTSFW procedures. The refinement approach does not affect the behavior of the procedures, only how the contents of certain parameters are to be populated and parsed.
The core of the refinement is as follows:
For the monitored parameters accessed via the Information Query and Cyclic Report procedures, the names of the parameters in the list-of-parameters parameters are to be interpreted as set names, e.g., the name "rcvrSignalStrength" is interpreted to be the name of the set of receiver strength values for all active functional resources that have a rcvrSignalStrength monitored parameter. The components of the qualified-parameters parameter are all to be of type character string, and the MD-CSTS will refine those character-string-types parameters to be sets of records of the form
<functional resource identifier>:<parameter value>
Thus for the previous example, if the parameter ""rcvrSignalStrength" is subscribed to (or requested in the GST invocation) when both the X-band and S-band receivers are active, the corresponding component of the qualified-parameters parameter might look like:
[parameter name = "rcvrSignalStrength", parameter type = octet string,
parameter value = "S-Band:<character string representation of dBm value>; X-Band:<character string representation of dBm value>", qualifier = 'valid']
The specification of the refinement would have to define the syntax of the character string (e.g., how the records of the set are separated, how different data types are to be represented I the parameter value field). We would probably pick an existing standard syntax (e.g., TLV, XML) instead of creating a new one as I did for the above example. The production specification section of the MD-CSTS would specify that the values of the monitored parameters from the various functional resources would be aggregated in this way and made available to the MD-CSTS instances.
For the Notification procedure, the MD-CSTS specification would refine the character-string-valued 'event value' component of the extension value of the notification-type to be of the form:
<functional resource identifier>:<resource event value>, where the ":<resource event value>" component is
optional.
For the example of the user subscribing to the 'carrier modulation unlocked' notification, when the carrier unlocks on the S-Band link, the resulting NOTIFY invocation contains the notification-type parameter value
[event name = "'carrier modulation unlocked', event value = "S-Band"]. (Note that in this example the resource event value doesn't exist.)
(You may have noticed that this approach is different from the distinguished name (or relative distinguished name) approach that I was promoting earlier. Under that approach, the equivalent information for the above receiver strength example would have been represented as two separate components of the qualified-parameters parameter:
[parameter name = "S-Band:rcvrSignalStrength", parameter type = Integer,
parameter value = <Integer dBm value>, qualifier = 'valid']
and
[parameter name = "X-Band:rcvrSignalStrength", parameter type = Integer,
parameter value = <Integer dBm value>, qualifier = 'valid']
Because this distinguished name approach generates two components in the qualified-parameters parameter for the single name n the list-of-parameters, it would have required redefinition of the behavior of the Information Query and Cyclic Report procedures, and has therefore been discarded.)
So this is the approach that I will be taking with the MD-CSTS specification. However, if one change were to be made to the CSTSFW specification, the refinement could be made even simpler. That change would be to add a SetOfRecords type to the supported types, where each record is has a record name and record value component, and the record value can be of any of the types currently allowed for the qualified-parameters type. In the ASN.1; the changes would look like:
TypeAndValue ::= CHOICE
{ integer [0] INTEGER
, intUnsigned [1] IntUnsigned
, duration [2] Duration
, characterString [3] VisibleString
, boolean [4] BOOLEAN
, octetString [5] OCTET STRING
, float [6] REAL
, time [7] IntUnsigned
, setOfRecords [8] SetOfRecords <-- new type
, valueExtension [100] Extended
}
SetOfRecords ::= SEQUENCE OF
{ record name VisibleString
, record value TypeAndValue
}
Having this structure available in the Framework would simplify the refinement of the MD-CSTS. Of course, it may only be useful to the MD-CSTS, and therefore putting it into the Framework might be questionable. I will proceed on the assumption that the change will not be made, but I will be able to incorporate the change if the WG decides that it is a good thing to do.
I would be very happy to receive any comments on this from anyone who is not already on vacation/holiday. Perhaps we can discuss it in our telecon on 11 August.
Best regards,
John
John Pietras
GST, Inc.
7855 Walker Drive, Suite 200
Greenbelt, MD 20770
240-542-1155
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
More information about the Css-csts
mailing list