[Css-csts] Use of Functional Resource Names in CSTS SFW operations and procedures

Mon Jul 29 11:02:52 EDT 2013

Margherita,
I agree with your proposal (to keep the functionalResourceName and add the functionalResourceType). The main point of my comment was that I thought that of the two (functionalResourceName and functionalResourceType), functionResourceType would probably have more widespread use because the user might not as easily know (or otherwise need to know) the FR Instance Numbers. I have no objection to retaining the functionResourceName.

Last week I sent to Yves a version of the CSTS SFW with the changes needs to specify the standard Framework behavior when labels are used in the subscription - that is that they apply only to the functional resource instances that are directly associated with the service instance that is executing the procedure. If we add the functionalResourceType option to the lists, then that qualification will have to be added for that value, too. I will go through the version that I sent to Yves and add the functionalResourceType options where appropriate. I think that I will be able to get that completed by sometime tomorrow morning (my time).

Best regards,
John

From: Margherita.di.Giulio at esa.int [mailto:Margherita.di.Giulio at esa.int]
Sent: Friday, July 26, 2013 9:45 AM
To: John Pietras
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org); css-csts-bounces at mailman.ccsds.org
Subject: Re: [Css-csts] Use of Functional Resource Names in CSTS SFW operations and procedures

Dear John,
Holger and myself  have made some brainstorming on the issue you have raised in your e-mail from 22 July (attached).

The outcome is that, we would favour leaving the Functional Resource option in.
In fact, we think it is very convenient (and practical) for a CSTS User of a Service to just request the delivery of  *all*  parameters belonging to the FR . Think of a (future) CSTS-based telemetry or telecommand service. The User would simply request all the parameters associated to that CLTU FR or RAF FR.

To be more specific, for the ListOfParametersEvents structure, we favour the following approach:

1) introduce the functionalResourceType option to the CHOICE. This is the "wild card"  to be used by all Services who are not aware - or not interested - of the FR number.  As said during the telecon ( and as per John's e-mail)  the standard behaviour is that for any label there could be at most only one instance of the parameter associated with the CSTS service instance

2) retain the functionalResourceName option in the CHOICE. This shall be mainly used by the MD Service, but may be used in the future also by other yet unknown services.

The above approach, while not forcing any Service to make use of the one or the other option, still offers the widest range of possibilities for the Service to be built on top the Framework. The Services shall simply refine the "offer" from the Framework, by choosing the one or the other option. This is, I think, the objective of a well-thought Framework.

Instead, if the FR options ( be it name or label) are not part of the CHOICE, we should describe somewhere ( Framework or Guideline) how a Service shall extend the ListOfParametersEvents structure in case all parameters of a FR are of interest to the Service User. Obviously the parameters can be listed by means of the paramEventName/paraEventLabel options,  but this requires adequate knowledge of the FR itself, it is less flexible (if a new parameter gets added to the FR, the list needs to be re-compiled) and, all together,  it is more error prone.

Please let us know how you see our proposal.

Kind regards,
Margherita

----------------
Margherita di Giulio
Ground Station Back-end Section (HSO-GIB)
European Space Agency ESA/ESOC
Robert-Bosch-Str. 5
D-64293 Darmstadt - Germany
Tel: +49-6151-902779
e-mail: Margherita.di.Giulio at esa.int<mailto:Margherita.di.Giulio at esa.int>

From:

John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>

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>>

Date:

22/07/2013 22:48

Subject:

[Css-csts] Use of Functional Resource Names in CSTS SFW operations and procedures

Sent by:

css-csts-bounces at mailman.ccsds.org<mailto:css-csts-bounces at mailman.ccsds.org>

________________________________

CSTSWG colleagues ---
At last week's telecon, we discussed various issues regarding the use of Labels in CSTS operations and procedures and arrived at the following decisions:
1.       In response to a subscription or query, Parameter or Event Names will always be reported/returned. There is no option to report/return a Label.
2.       Labels can be used in subscriptions or queries, but we decided that the standard behavior would be that for any label there could be at most only one instance of the parameter associated with the CSTS service instance. This would apply to labels that are individually specified in the list-of-parameters (for the Cyclic Report procedure or procedures using the GET operation) or list-of-events (for the Notification procedure) , labels represented by a list name. or labels represented by a default list. For the great majority of CSTSes that are  expected to use GET, Cyclic Report, or Notification the service will have access to only those parameters and events that are directly associated with their own production or provision. By declaring this to be the standard behavior, the service specifications for such "normal" CSTSes will be able to use these procedures without further derivation or refinement.
3.       Of course, the Monitored Data (MD) service will *not* be constrained to access parameters and notifications associated with its own production and provision. In the case of the MD-CSTS, the behavior of the Cyclic Report, Information Query, and Notification procedures will have to be extended to allow a single label to represent *all* instances of that parameter/event in the whole Service Package of which the MD-CSTS instance is a part. This was deemed to be the best approach because it concentrates all the need to derive procedures in only one service (the MD-CSTS specification).

I took the action to add the necessary rewordings to the CSTS SFW, and Yves sent me a copy of the most-current version to work on.

In working on the draft, I came across a new issue. The GET invocation, Cyclic Report START invocation, and Notification START invocation allow the list-of-parameters and list-of-events (respectively) to contain a single Functional Resource Name. I'm pretty certain that the motivation for this option was driven by the MD-CSTS case: it is certainly a convenient notion to ask for all parameters/events for an instance of a Functional Resource type. However, its usefulness is not quite so obvious for what we are now calling the normal or standard case, where the scope of the parameters/events to be reported is limited to those that are directly associated with the production of provision of the service instance itself.

If we continue to keep the Functional Resource Name as an option for the standard procedures, I think that at a minimum notes should be added to point out that such selections are valid only for Functional Resource instances that are directly associated with the service performing the procedure: any non-associated FR Name will result in a negative result with diagnostic 'unknown Functional Resource Name'.

And if we *do* continue to keep the Functional Resource Name as an option for the standard procedures, it seems reasonable to ask whether it makes sense to allow the Functional Resource Type to be requested. Actually, to me it seems more likely that the user of a "normal" service might know the FR Type than the actual FR Name: the type will be statically associated with the service type (e.g., a return SLE-like CSTS will always have a return carrier FR Type associated with it) but the name is nominally dynamically assigned by Service Management. Note that if we were to allow the FR Type to be added to the options there would still be the possibility that service user could ask for an FR type that is not associated with the service type and therefore would cause a negative result.

Another approach would be to remove the FR Name option from the Framework procedures and let it be added as an extension by the MD-CSTS, which is the service where such a wild-card capability is really useful. I think that I'm leaning toward this option.

I apologize for always coming up with these last-minute stumbling blocks.

Best regards,
John
 _______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org<mailto:Css-csts at mailman.ccsds.org>
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts

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=01K51LMzj&m=2cdd7bd84eab&c=s>
Not spam<https://filter.gst.com/canit/b.php?i=01K51LMzj&m=2cdd7bd84eab&c=n>
Forget previous vote<https://filter.gst.com/canit/b.php?i=01K51LMzj&m=2cdd7bd84eab&c=f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130729/8cb07434/attachment-0001.htm