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

Fri Jul 26 09:44:40 EDT 2013

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

From:
John Pietras <john.pietras at gst.com>
To:
"CCSDS_CSTSWG (css-csts at mailman.ccsds.org)" <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

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

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