[Css-csts] RE: Effects of using individual Labels with MD-CSTS
John Pietras
john.pietras at gst.com
Mon Jul 15 14:38:50 EDT 2013
Yves,
Regarding the question of whether the service returns names or labels: I thought that during the last CSTSWG telecon the it was suggested that some implementations of some services might not have access to the FR Instance Number and/or that the instance number may not be necessary. I believe that the example used was that of a normal CSTS reporting its Production Status - the user knows implicitly that the service is reporting its own Production Status and so the instance number is not strictly needed.
One possible way to work around this might be to state in the Framework that the name (i.e., the inclusion of the instance number) is required unless there is only one possible FR instance associated with each parameter or event. In that case, it is permissible to supply just the label. In such a case, the use of the label (i.e., the lack of this instance number) is interpreted as " 'this' CSTS instance" or "the only instance of the functional resource type associated with 'this' CSTS instance".
If the affected Framework procedures were written in this way, then I believe that it would be possible to use those procedures in specifications without having to extend or refine them regarding whether they transmit/return names or labels.
NOTE - If in the end the WG decides to keep it simple and always send the name, then qualified parameter should be (re-)redefined to only include names.
There is still the issue, however, of what it means when a user puts a label (as opposed to a name) in a subscription request or query. So far, we have identified two different possible behaviors:
1. In some services, there may be only one possible instance of a parameter or event (that is, there is only one instance of the FR Type that generates the parameter or event), but the user does not know what the instance number of the FR is. There are two subcases: (a) where the parameter/event is part of a list (which by definition is constructed prior to the scheduling of any Service package and therefore unable to "know" which FR instance numbers apply) or (b) where the user simply doesn't know (or want to have to use) the FR instance number. In subcase (b), it is theoretically permissible to just use a label because there can be only one instance of that parameter/event. At the last CSTSWG telecon, the proposal was made to support the use of labels instead of names in this behavior for purposes of user ease.
2. In some cases, there may be *multiple* possible instances of a parameter or event, and the user wants all instances to be reported (this is the MD-CSTS case). Again, there are two subcases: (a) where the labels are part of a list, because it is not possible to use names in a list that is created before the Service Package is scheduled, and (b) where the user would like to use the label as a short-hand for "give me all instances of this parameter/label." We have recognized case (a) for some time, but case (b) is just a recent possibility.
This is the issue that I think we have to address with refinement or extension of behavior, for at least some CSTSes. The approach that I illustrated in the updated MD-CSTS that I posted last week addressed the problem in the context of a Framework that simply defers the behavior to the individual service specification. In this approach, all service specifications would have to define the behavior, and therefore all service specifications would have to have sections dedicated to the procedures for which the behavior needs to be extended.
I can think of two other alternate approaches that would reduce the need to specify behavior for at least some service instances. The first alternate approach is the one that I briefly identified in my previous email. That is, the Framework specifies two possible standard behaviors: (1) only one parameter/event instance is to be reported/returned for each label or (2) all parameters/events of configured Functional Resources in a Service Package are to be reported. The Framework (and/or Guidelines) specifies that each service that uses one of these procedures must refine the procedure to identify which behavior applies.
The second alternate approach would have the Framework explicitly state the standard behavior as being that only one parameter/event instance be reported for each label. NOTEs would be added to the framework that would state (a) that this behavior is applicable only in services where there is a single unambiguous possible instance for the label, and (b) that the behavior can be modified by services for which the single unambiguous instance assertion doesn't hold.
The advantages of the first alternate approach with respect to the approach that I used in the last MD-CSTS update is that the changes can be handled as refinements and not extensions. That eliminates the need to create now procedure types and procedure type identifiers. A disadvantage is that it names only the two standard behaviors, the second of which is very much tailored to the MD-CSTS case. If we have a service in the future that wants yet a different behavior then an extended procedure will still have to be defined.
The main advantage of the second alternate approach over the first alternate is that for the class of services for which it is possible to assert that there will be only one instance of each parameter or event, the Framework procedures can be used without derivation or extension. If we believe that this will be the normal case, then most CSTSes can adopt the procedures and GET operation as-is. A second advantage (of sorts) is that it doesn't orient the Framework procedures to any specific service (in this case, MD-CSTS). The flip side is that for a service such as MD-CSTS, the different behavior is indeed an extended behavior and would result in the specification of new extended procedures with their own procedure instance identifiers.
As test cases for these two alternate approaches, I reworked the most-recent draft of the MD-CSTS specification to illustrate each approach and posted the results on the CWE. Note that in both cases I assumed that it is not necessary to specify that MD-CSTS procedures always report/return Names (either because they are always defined as being Names or because the Framework procedures are defined in a way that implies that Names would be used for the MD-CSTS since multiple values for each subscribed Label are available).
The draft corresponding to the first alternate approach (MonitoredDataCSTS_W-0.15_Alt1-13-07-15.doc ) can be found at URL
http://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/Future%20Services%20using%20Toolkit/MonitoredDataCSTS/MonitoredDataCSTS_W-0.15_Alt1-13-07-15.doc.
The changes in this version from the previous version are found in sections 3, 4, 5, 6, and Annex A. The changes in section 3-6 all involve restating the procedures as being refined (as opposed to refined and extended).
The draft corresponding to the second alternate approach (MonitoredDataCSTS_W-0.15_Alt1-13-07-15.doc ) can be found at URL
http://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/Future%20Services%20using%20Toolkit/MonitoredDataCSTS/MonitoredDataCSTS_W-0.15-Alt2-13-07-15.doc.
The changes in this version from the previous version are also found in sections 3, 4, 5, 6, and Annex A. The changes in section 3-5 involve restating the Cyclic Report procedures as being extended (as opposed to refined and extended). The Notification procedure is still defined as refined and extended.
I look forward to hearing/reading your comments and/or discussing this topic with you.
Best regards,
John
From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int]
Sent: Monday, July 15, 2013 2:34 AM
To: John Pietras
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org); css-csts-bounces at mailman.ccsds.org
Subject: Re: Effects of using individual Labels with MD-CSTS
Dear John,
The problem I understand is that leaving in the Framework all the possibilities implies that the service as to refine the behaviour to ensure the service provider returns with a predictable behaviour names or labels.
I see in your proposed refinement that the intention is to enforce the provider to return names. As you correctly points out, this requires a new refined procedure.
Reading your new service, the questions I have are:
1. what do we gain in leaving the flexibility? In my view not much.
2. What do we loose if the Framework imposes tor return names whatever the user requests (names or labels)? Considering that the overall approach is based on names, I do not think we do loose much.
In view of the service specifications difficulties you are facing and considering that we do not loose much (It's my feeling), I would propose that whatever is requested (names or labels), the service provider always return names.
That approach will in addition ensure a unique identification when troubleshooting will be required.
If everybody agrees and in view of the difficulties I am prepared to update the Framework for imposing the service provider to always return names.
Please let me know if you (the working group) would see an issue with that change and if you would agree.
Best regards
Yves
From:
John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>
To:
"Yves.Doat at esa.int<mailto:Yves.Doat at esa.int>" <Yves.Doat at esa.int<mailto:Yves.Doat at esa.int>>
Cc:
"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>>, "css-csts-bounces at mailman.ccsds.org<mailto:css-csts-bounces at mailman.ccsds.org>" <css-csts-bounces at mailman.ccsds.org<mailto:css-csts-bounces at mailman.ccsds.org>>
Date:
09/07/2013 22:48
Subject:
Effects of using individual Labels with MD-CSTS
________________________________
Yves and CSTSWG colleagues ---
Yesterday I responded to Yves' message (see below). With regard to his question about whether the CSTS SFW should specify the behavior of an operation of a procedure when a Label is used in the subscription (e.g., can the return contain either a Label or a Name?), Yves expressed a preference for not locking it down in the CSTS SFW. I agreed with that preference, and suggested that the CSTS SFW could formally defer the specification of the behavior to the individual services. When I wrote my response yesterday, I thought that it would be sufficient to address the behavior as a refinement of some operation parameter values.
Yesterday and today I modified the MD-CSTS specification to address the the behavior with respect to what gets reported/notified when a Label is used in the subscription or query. Unfortunately, it looks like the effect on the MD-CSTS (and other services using the Cyclic Report and Notification procedures and the GET operation) may be more extensive than I had originally anticipated.
I've uploaded the modified MD-CSTS specification to the CWE at URL
http://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/Future%20Services%20using%20Toolkit/MonitoredDataCSTS/MonitoredDataCSTS_W-0.15-13-07-09.doc
The complications arise because according to the CSTS Guidelines (most recent version posted on the CWE - October 2012), a change in or addition to procedure behavior is defined as an extension, which in turn requires that a new Procedure Type Identifier be defined (along with a new name for the procedure) and a new procedure specification section to be added to the service specification.
I tried to figure out how to add the specification of such behavior in the service specifications without needing to create extended procedures, but so far I have not had success. The best thing that I have been able to think of so far is that we might define a standard set of behaviors in the CSTS SFW and require that a service specification select among them (sort of like how we have defined standard state machines from which each service specification selects the one to which it conforms). If we have a standard set of behaviors, a service that selects which of those behaviors that applies to it could be considered to be refining (instead of extending) the behavior, and that would not involve creating a new Procedure Type Identifier. The Guidelines would also have to change to allow refinement of behavior.
How should we proceed? Do we just accept that any service that uses the Cyclic Report or Notification procedure or any procedure that uses the GET operation will have to be extended (that is, it will be impossible to simply adopt the Framework version of the procedure), or should we try to figure out how to "standardize" this behavior in the Framework? I look forward to your (and other CSTSWG colleagues') responses.
Best regards,
John
From: John Pietras
Sent: Monday, July 08, 2013 11:57 AM
To: 'Yves.Doat at esa.int'
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>); css-csts-bounces at mailman.ccsds.org<mailto:css-csts-bounces at mailman.ccsds.org>
Subject: RE: [Css-csts] RE: Updated CSTS SFW on CWE - labels
Yves,
My comments are interleaved below.
Best regards,
John
From: Yves.Doat at esa.int<mailto:Yves.Doat at esa.int> [mailto:Yves.Doat at esa.int]
Sent: Monday, July 08, 2013 2:37 AM
To: John Pietras
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>); css-csts-bounces at mailman.ccsds.org<mailto:css-csts-bounces at mailman.ccsds.org>
Subject: Re: [Css-csts] RE: Updated CSTS SFW on CWE - labels
Dear John,
Thanks for your reply.
1. No mixing of Names and Labels
As you did not really object I kept the definition as is not allowing the mixture of names and labels in a request.
The defined ASN.1 has not been changed and read as follows:
ListOfParametersEvents ::= CHOICE
{ defaultList [0] NULL
, paramEventNames [1] SEQUENCE OF Name
, paramEventLabels [2] SEQUENCE OF Label
, listName [3] VisibleString
, functionalResourceName [4] FunctionalResourceName
}
My main argument to keep the definition as is, is simplicity. Allowing mixing would be possible but would introduce a complexity in the definition. The consequence of this approach is that a service user that will need to retrieve names and labels will have to issue two requests.
In case someone would have a concern with that approach please let me know.
As I stated in my earlier message, I have no objection to not allowing the mixture of Names and Labels. However, there two places in my proposed revised text ("921x1r2[Draft 201306] - Return Services-JVP") that imply that they could be mixed. Below are proposed rewordings:
a) Section 3.11.2.3.1 (b), second sentence: change "The list of unknown Parameter Names and Parameter Labels shall be returned with the diagnostic."
to
"The list of unknown Parameter Names or Parameter Labels shall be returned with the diagnostic."
b) Section 4.7.4.1.3.1 (b), second sentence: change "The list of unknown Parameter Names and Parameter Labels shall be returned with the diagnostic."
to
"The list of unknown Parameter Names or Parameter Labels shall be returned with the diagnostic."
2. Return of Names when Labels are requested:
Another aspect which you are addressing is what a service provider shall return in case a label is required. At the moment he can return a name or a label.
In your proposed scenario, in case the service provider only "knows" one name whether he returns a name or a label does not make any difference and can be accepted.
However in the case a service provider would "know" more than one name and return a label, the service user may be misled as he cannot be sure if the returned information is the requested on.
A solution would be to force the service provider only to return names. In case a service user would request a label and the service would "know" more than a name, he would return all "known" names. The service user would have to filter/search himself for the desired one. This would resolve the uncertainty but I am not sure is the service user would "know" how to filter.
The question is: Do we want the service provider to return only names and do not allow the return of labels? On one hand I adhere to this limitation, on the other hand this implementation would remove flexibility for the service definition and may be counter-productive.
Currently the definition allows the service provider to return names and labels.
This solution impacts the current definition and I would appreciate to get the position of the group members.
(In case my explanation is not clear we should discuss the topic in a next teleconference.)
It was my understanding from our discussion at the last telecon that we decided that if the user subscribed to a parameter or event using its Name, then the report/notification/etc. would have to use the full Name also. I don't believe that we had any decision on what has to be returned when a Label is used in the subscription. In "921x1r2[Draft 201306] - Return Services-JVP", I tried to address this by proposing explicit requirements that (a) state that a Name returns a Name, and (b) defers the decision about what gets returned in response to a Label to the service specifications that use that procedure.
Specifically, for the Notification procedure, the relevant requirements are:
4.8.3.2.3 If an event is subscribed in terms of an individual event name, the corresponding notification-type parameter (see 3.10.2.2.3.1) shall contain that event name.
4.8.3.2.4 The service specification or derived procedure shall specify the conditions under which it is permissible or required to use the event label or event name in a notification-type parameter that corresponds to an event that is subscribed in terms of an event label.
For the qualified parameters (which are returned for all procedures that deal with parameters) the relevant requirements are:
B2.3 If a parameter in the list-of-parameters parameter is identified by an individual parameter name, the corresponding qualified parameter shall include that parameter name.
B2.4 The service specification or derived procedure shall specify the conditions under which it is permissible or required to use the parameter label or parameter name in a qualified parameter that corresponds to a parameter in the list-of-parameters parameter that is identified by an individual parameter label.
If the CSTSWG agrees with this approach (Names result in Names, but the result of Labels is determined by the service) then I think the above requirements largely resolve the problem. The only resulting issue that I can think of is how such definition should be documented in the service specifications. I believe that since it would be a "down selection" of existing possibilities (Names, Labels, or Names and Labels) it should be treated as a refinement. Does this seem correct to the rest of the CSTSWG?
The procedures in some services may be perfectly unambiguous with returning labels - e.g., the production status of an SLE-like CSTS can be assumed to always apply to the production associated with that CSTS instance, and so the instance number is not necessary.
However, for something like the MD-CSTS, it will always be necessary to return full Names. I will revisit the MD-CSTS specification to ensure (a) that it handles individual Labels as well as Names in the list-of-parameters and list-of-events parameters and (b) that it is clear that Names are always returned regardless of whether Names or Labels are used in the subscriptions. If we agree that this should be treated as a refinement, then I'll make the appropriate changes to the MD-CSTS specification.
Best regards
Yves
__________________________________________________
Head of the Ground Facilities Infrastructure Section (HSO-ONI)
in the Ground Facilities Operations Division
ESA/ESOC Robert-Bosch Strasse 5
D-64293 Darmstadt, Germany
Tel.: +49 (6151) 90.2288 Fax:+49 (6151) 90.3046
Internet: http://www.esa.int/
__________________________________________________
This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
________________________________
NOTE: This message was trained as non-spam. If this is wrong, please correct the training as soon as possible.
Spam<https://filter.gst.com/canit/b.php?i=01K0uAm5Q&m=8749186f4733&c=s>
Not spam<https://filter.gst.com/canit/b.php?i=01K0uAm5Q&m=8749186f4733&c=n>
Forget previous vote<https://filter.gst.com/canit/b.php?i=01K0uAm5Q&m=8749186f4733&c=f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130715/c3317285/attachment.htm
More information about the Css-csts
mailing list