[Css-csts] Revised Forward Procedures for integration into the Framework

Thu May 2 11:50:55 EDT 2013

Dear Wolfgang,
thank you for this update.

Herewith is my feedback, as well as one minor further comments:

Buffered DPP

WH1: It is true that, being the case of a buffer containing only one 
PROCESS DATA invocation described in Req 1.1.4.2.1.6, the Note 2 may look 
redundant. However I prefer leaving the Note where it is. In fact, the 
Note tells about the feature, and the Requirement states how to handle it. 
In general, Notes like this help understanding the service.

Question on Req. 1.1.4.2.2.7  :  What are the implications of having the 
processing-latency-limit set to zero in the timely mode? If this parameter 
is not controlled by the Provider, should we add a Note to tell what are 
the implications on the User?

Simple DPP
WH1: I am not sure about the meaning of this comment. The service 
described here is sequence-preserving, Therefore the Provider shall always 
check the value of the counter of the new incoming data unit only against 
the previous one.

Sequence Controlled DPP:

WH1: I fully agree that the User's behaviour shall be removed from the 
specification. This, in fact, has never been specified, and placing it 
here would make the approach for this procedure not consistent with the 
rest of the book ( and with any other CSTS book).

WH 2 and WH 5: I understand your concern about the diagnostics, however I 
am not sure as to why we decided to diverge from the previous approach, 
where the ?unable to process? diagnostic covered two cases: production 
halted and production interrupted. That is, it covered the permanent and 
the temporary condition for being unable to process. This was also the 
approach from the SLE books.
In that approach, the diagnostic b only reported about the case where the 
data unit has expired.
Can't we retain that approach?
If instead there are good reasons for diverging from that approach, then I 
agree with you that there should be a diagnostic also about inability to 
process due to  "interrupted" state.

WH3 : I think this depends on how the production engine is conceived. The 
wording "any data unit"  makes the statement generic enough.

WH4 : I see that  the accuracy of the production time may be an issue. 
This, however,  entails the behaviour of the production engine, which we 
normally do not specify, (The way the Production engine works is certainly 
different from Agency to Agency or even from Provider to Provider). 
Also, if we embark in the definition of the accuracy of a production 
engine, in the future we will have to define the accuracy of the ERT in 
the telemetry services, whenever these will be ported from SLE to CSTS.
In SLE as well the accuracy had not been addressed in any of the books.
In conclusion, I would leave this out from the CSTS Framework.
A derived service may still work this out. 
What do you think?

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:
Wolfgang.Hell at esa.int
To:
css-csts at mailman.ccsds.org
Date:
27/04/2013 15:53
Subject:
[Css-csts] Revised Forward Procedures for integration into the  Framework
Sent by:
css-csts-bounces at mailman.ccsds.org

Dear CSTS WG Members,

As agreed with Margherita during the Bordeaux meeting, I have assigned
highest priority to the consolidation of the three Forward Procedures so 
that
these can be integrated into the Framework asap. I have uploaded the 
results
of this activity to

 (Embedded image moved to file: pic01814.gif)  

 The CCSDS Collaborative Work Environment (CWE) > Cross Support Services 
Area 
 (CSS) > Documents > CSS-CSTS > CWE Private > Working Materials > DPP 
Working 
 Papers  

The vast majority of the issues raised before and aty the Bordeaux meeting
have been taken care of. A few minor points are addressed by means of
comments in the documents. Given that the next scheduled meeting is not
before June, I would appreciate if you could provide feedback via email so
that I can close this activity and provide Yves with stable input to the
Framework.

Best regards,

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

[attachment "pic01814.gif" deleted by Margherita di Giulio/esoc/ESA] 
_______________________________________________
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/20130502/04c68076/attachment.htm