[Css-csts] new Data Processing procedure uploaded

[Ray, Timothy J. (GSFC-583.0)]

Dear Working Group members,

 

I have uploaded a new version of the Data Processing procedure that has
been edited in accordance with the suggestions agreed to in Crystal
City:

 

"Make the table formats consistent with the formatting used in other
procedures".

Done.

Note:  In order to get the proper format, existing tables were copied
from other procedures and then filled in with the information
appropriate for the Data Processing procedure.  In the case of the
provider state table, the column widths were adjusted so that
'(ProcessDataInvocation)' would not be split into
'(ProcessDataInvocatio' on one line, and 'n)' on the next.

 

"Ensure that any 'note' that is actually a requirement is changed to a
more appropriate syntax".  

Done.  I looked at every note:

            2.2.1   This is not a requirement.

            2.3.1   Ditto.

            2.3.3   Ditto.

            2.4.2   Ditto.

            2.4.3.1  Ditto.

            2.4.3.2  This section has been modified to incorporate notes
1 and 2.

 

"Make sure all paragraphs are numbered".  

All paragraphs are now numbered.  However, I was not able to get the
right 'style' for 'Paragraph 4' and 'Paragraph 5'.  So, I left the style
as 'Normal' and typed the number in (for example, "2.4.2.1  ").  These
numbers are highlighted in yellow to call attention to the fact that
additional editing is needed to get their style correct.

 

"Follow the agreed-upon outline (the 'Behavior' section should come down
a level')."

Done.

 

"Be more careful about specifying the timing of data processing".  

Section 2.4.2 has been modified to more carefully specify the time when
processing begins if no earliest-data-process-start-time is specified.

 

"be more clear about the use of buffering (in particular, when is a
data-unit removed from the buffer?)"

Section 2.3.3 has been modified.

 

(from a Martin G. response to an Yves email - comment #4)  "I noted that
the text for the negative feedback is problematic, as it says 'If a data
unit is discarded without having successfully completed processing
(regardless of whether processing was started or not) the provider shall
always notify the user.'   This is only true for a data unit for which
the provider has started processing or has attempted to start
processing.  For data in the buffer that are discarded no report is
sent."     

Section 2.4.3.2 includes this suggestion.

 

"add a note to section 3.3.1 explaining why there is redundancy."

Done.

 

"Add a 'reset' directive" (see section 5.10 of the meeting minutes).

Done.  Added section 2.7 (description of activities).  Added the
EXECUTE-DIRECTIVE operation to table 3-1.  Added section 3.4 (use of
EXECUTE-DIRECTIVE operation).  Added event #11 to the provider state
table ('reset directive received'), and compound action 'reset'.

Several decisions had to be made about the EXECUTE-DIRECTIVE operation:

-          Is the generic operation extended?  Yes, because another
value is defined for the event-identifier.

-          Is the generic operation refined?  No.

-          Is this operation blocking or non-blocking within the
procedure?  I chose 'blocking' because a 'reset' is similar to a 'stop'
(and 'stop' is blocking).

 

 

 

There are also some changes that were not requested in Crystal City:

 

Section 2.4.3.2a was changed to resolve a conflict between it and
section 2.4.3.2.d.  The conflict occurs when the production status is
'interrupted' and the latest-data-process-start-time is reached.  If
section 2.4.3.2a is applied, then the notification-type would be 'data
expired'.  If section 2.4.3.2d is applied, then the notification-type
would be 'production interrupted'.  The change attempts to clarify that
'data expired' does not apply if the production status is 'interrupted'.

 

In section 2.6.1 the word 'can' was changed to 'shall' to indicate that
it is required rather than optional.

 

In section 3.3.1.2, several instances of the word 'process' were changed
to 'processing' for consistency's sake.

 

In the provider state table, the action 'buffer data unit' was changed
to a compound action (of the same name) that includes 'buffering the
data unit' and also refers to processing the data unit.  The intent is
to clarify the fact that processing must be performed on the data unit.

 

In the provider state table, the compound action 'initiate stop' was
changed.  Prior to the change, it suggested that the processing of any
in-progress data unit must complete before issuing a +StopReturn.  It is
now consistent with the state tables in the SLE Forward CLTU and Forward
Space Packet services.

 

Best regards,

Tim

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20080331/540e54ba/attachment.htm