[Css-csts] Blocking/non-blocking operations in derived procedures

Wed Mar 13 07:53:34 EST 2013

Yves,
I tend to agree with you - I can't see any reason to allow it to change in a derived procedure. The only thing that made me question it is that for every derived procedure in a service specification we include a “Procedure Blocking/Non-Blocking” column in the table that identifies the operations of the procedure. Since we have in general tried to include in the service specifications only new information or information that modifies the parent procedure, the presence of that column in the table for the derived procedures raised the question in my mind.   

If the consensus of the CSTSWG is that the B/NB behavior cannot change in a derived procedure, we should probably state that in some normative fashion, probably in the Guidelines. Even though we are not actively working on the Guidelines now, I could make the related changes to the working draft and post it to the CWE. But I will wait to hear if anyone has a counterargument (that is, a reason to allow the B/NB behavior to be changed from that of the parent) before I do so.

Best regards,
John

-----Original Message-----
From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int] 
Sent: Wednesday, March 13, 2013 5:03 AM
To: John Pietras
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org); css-csts-bounces at mailman.ccsds.org
Subject: Re: [Css-csts] Blocking/non-blocking operations in derived procedures

Dear John,

Looking at the Framework, I do not see how an operation can be changed from blocking to non-blocking and vice-versa.
In  my view this is not possible with the current definition.

In case this would become a requirement, we would have to look on the impact on the Framework.

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

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

  To:         "CCSDS_CSTSWG (css-csts at mailman.ccsds.org)" <css-csts at mailman.ccsds.org>                                             

  Date:       12/03/2013 20:00                                                                                                     

  Subject:    [Css-csts] Blocking/non-blocking operations in derived procedures                                                    

  Sent by:    css-csts-bounces at mailman.ccsds.org                                                                                   

CSTSWG colleagues ---
A question as occurred to me that may have been discussed in the WG at some point, but I don’t recall it,.

The question is whether it is possible to change the blocking/non-blocking
(B/NB) behavior of an operation in a derived procedure. The CSTS SFW states that it is the procedure that defines the B/NB behavior for each of its operations, and this is done for the procedures defined in the SFW itself.

If a service specification creates a service-original procedure or derives a procedure by adding one or more new operations, then it seems clear that the specification of that procedure must specify the B/NB behavior of the new operations (all of them in the case of a service-original procedure, the added ones in the case of the derived procedure). But can the service specification redefine the B/NB behavior of an operation that is inherited from the parent of the derived procedure?

Currently, the Guidelines and the TD-CSTS specification include a “Procedure Blocking/Non-Blocking” column in the table that identifies the operations of derived and service-original procedures (the MD-CSTS book contains no such table, since it uses the SFW procedures without derivation). The operations of the TD-CSTS Buffered Tracking Data Message Delivery procedure have the same B/NB behavior as the parent Buffered Data Message procedure, but could we change the B/NB behavior or one or more of the operations if we wanted to?

I have not been able to find this question addressed in the CSTS SFW or the Guidelines.

If we do allow the B/NB behavior to change, should such a change be somehow highlighted in the operations table – e.g., with an asterisk (*) by the designation to show that it is different from the parent operation?

If we do not allow the B/NB behavior of inherited operations to change, one might be tempted to eliminate the “Procedure Blocking/Non-Blocking” column altogether, but that would not support the addition of operations to a derived procedure or the creation of a service-original procedure. So we probably need to keep the column in the table, even if it has redundant information (in that it merely repeats the B/NB status of the existing inherited operations from the CSTS SFW).

Thanks for your thought on this.

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.