[Css-csts] Data-Processing Procedure - Comments
Yves.Doat at esa.int
Yves.Doat at esa.int
Wed Nov 21 07:49:26 EST 2007
Dear Martin,
Please find attached the version Tim had at the end of the meeting in
Heppenheim. This is the latest I have but Tim may have a new one.
I also copy here the relevant ASN.1 derived from the procedure. The
definition of DataProcessingNotifyInvocation will have to be reviewed.
===================
-- The definition of the Notification types
-- follows the definition in ANNEX B
NotificationTypes ::= CHOICE
{ productionConfigured [0] Extended
, productionInterrupted [1] Extended
, productionHalted [2] Extended
, productionOperational [3] Extended
, notificationExtension [4] Extended
}
===================
NotifyInvocation ::= SEQUENCE
{ standardInvocationHeader StandardUnconfirmedInvocationHeader
, notificationType NotificationTypes
, extensionParameter Extended
}
===================
-- This extension is to be sent with any type of NotifyInvocation
-- (type defined in C2.7)
DataProcessingNotifyInvocation ::= SEQUENCE
{ dataSequenceLastProcessed CHOICE
{ noDataProcessed [0] NULL
, dataProcessed [1] SEQUENCE
{ dataSequenceCounter DataSequenceCounter
, dataProcessingStatus CHOICE
{ successfullyProcessed [0] DataProcessingStartTime
, expired [1] NULL
, processingInterrupted [2] DataProcessingStartTime
, processingStarted [3] DataProcessingStartTime
, processingNotStarted [4] DataProcessingStartTime
}
}
}
, dataSequenceLastOk CHOICE
{ noSuccessfulProcessing [0] NULL
, dataSequenceCounter [1] SEQUENCE
{ dataSequenceCounter DataSequenceCounter
, dataProductionTime Time
}
}
, productionStatus INTEGER
{ productionConfigured (0)
, productionInterrupted (1)
, productionHalted (2)
, productionOperational (3)
, notificationExtension (4)
}
, extensionParameter Extended
}
DataProcessingStartTime ::= Time
DataSequenceCounter ::= IntPosShort
-- Additional NotificationTypes:
DataProcessingNotifyType ::= CHOICE
{ dataExpired [0]DataProcessingNotifyInvocation
, dataProcessingSuccessfullyCompleted [1]DataProcessingNotifyInvocation
, notificationExtension [3]Extended
}
===================
(See attached file: CSTS Data-Processing Procedure 03.10.2007 11pm.doc)
Best regards
Yves
Martin Götzelmann
<martin.goetzelman
n at vega.de> To
<Yves.Doat at esa.int>
21/11/2007 13:09 cc
Subject
RE: [Css-csts] Data-Processing
Procedure - Comments
Dear Yves,
I have a few remarks to your comments interspersed with the original text.
By the way - is there an update to this procedure? On the CCSDS site I only
found the issue from March this year.
==================================================================
COMMENT 1:
The format should be revised to be in line with the rest of the document,
e.g.: tables borders, tables in portrait (not in landscape), table 3-1,
section 2.4.1 does not follow the agreed structure (Feedback), ...
==================================================================
COMMENT 2:
Section 1.2.2 specifies that for each data unit immediate feed-back is
provided (acknowledge). In fact the Process-Data is a two ways operation and
we should not mention 'acknowledge' but 'return'.
However I note that the procedure has two new notifications (section 3.3.2)
'data expired' and 'data processing successfully completed'. We would
consider this operation as a 3 ways operations, we would have an
acknowledgement and we could cover those two notifications as part of the
return. Can we consider that the PROCESS-DATA operation could always be
three-ways?
---------------------------------
[MG] The reason not to use a three-way operation is that derived procedures
may have more than one processing report to send. For instance, CLTU only has
one report (CLTU radiated) but FSP has three reports (packet processing
started, packet radiated, packet acknowledged). The note in section 2.4.3.1
was intended to point this out.
==================================================================
COMMENT 3:
Section 2.3 states that if the provider accepts a Data-Unit, it is buffered.
I am missing in the description when is the data-unit removed from the
buffer?
Do we really want the procedure specifies the data buffer behaviour? Is that
not implementation specific? Can we avoid talking of a data buffer?
---------------------------------
[MG] In this respect we tried to remain as close as possible to the CLTU
specification. Somehow you need to express that the Provider shall process
the data units in the sequence received and shall not loose any data. As data
can be sent well in advance there will also be some limit on the amount of
data that can be buffered. I guess all of this can be said somehow without
referring to a buffer, but I feel introducing the concept of a buffer might
make this better understandable.
==================================================================
COMMENT 4:
Section 2.4.3.2 specifies that the provider shall always notify the user on a
negative completion of the processing. Does that mean that the
process-completion-report parameter of the PROCESS-DATA operation shall
always be set to true? What would be the behaviour. I think the behaviour
associated to the process-completion-report parameter is to be clarified.
--------------------------
[MG] I agree that this should be clarified. Reference to the
process-completion-report parameter is actually only made in the section on
positive feedback but it would be better to say in the section on negative
feedback that this is sent regardless of the setting of the
process-completion-report parameter.
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.
==================================================================
COMMENT 5:
I am working on the ASN.1 definition and that triggers the following comment.
I have a problem with the NOTIFY extension and I will try to explain the
problem hereafter.
The types of notifications agreed are the following:
production status configured;
production status interrupted;
production status halted;
production status operational
notification extension
In your notification extension you request whatever notification to carry
similar detailed information, i.e. data-sequence-last-processed,
data-processing-status,data-processing-start-time, data-sequence-last-OK,
data-production-time). So far so good. I can map the required information as
follows:
Change the common type NotificationTypes to allow carrying external data
whatever notification is used;
Define a structure that covers your need: no problem I have done it (I do
not attach it here otherwise the mail would be too messy)
Now comes the problem. In addition to the above list the NOTIFY shall also
carry the production status.
As a consequence, the provider could send a NOTIFY with a NotificationType
"productionConfigured" that would contain your proposed structure containing
the production-status information.
I propose to remove the 'production-status' parameter from the NOTIFY
extension to avoid redundancy.
--------------------------------------
[MG] Also in this case we tried to keep as close as possible to the CLTU
specification, which requires the production status in every notification. I
am afraid that I o not fully understand the problem yet without seeing the
ASN.1 specification.
==================================================================
COMMENT 6:
The procedure requires the following two new notification types: 'data
expired', 'data processing successfully completed'.
I have the feeling that:
'data expired' is redundant with the value 'data expired' of the
'data-process-status'
'data processing successfully completed' is redundant with the value 'data
successfully processed'
I wonder whether the 'data-process-status' should not be in fact a
notification type.
Let's assume we convert this parameter into a notification type, we would
have in addition to the standard notification types:
data successfully processed
data expired
data processing interrupted
data processing started
data processing not started
Consequence: In case the production status would change to interrupted while
a PROCESS-DATA is not completed, the user would get two notifications:
'production status interrupted' and 'data processing not started'. The next
question would be to know whether we need all this progress information when
processing the data.
--------------------------------------
[MG] The definition of the 'data-process-status' was supposed to be a direct
translation of the 'cltu-status' and should describe the status of the
'data-sequence-last-processed'. My understanding of this approach in CLTU is
that this status is not necessarily the same as the notification. For
instance in the notification 'processing halted' the cltu-status could be
'successfully processed' or 'interrupted'.
Kind Regards,
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: =?ISO-8859-1?Q?CSTS_Data-Processing_Procedure_03=2E10=2E2007_11pm=2E?=
=?ISO-8859-1?Q?doc?=
Type: application/msword
Size: 151552 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/css-csts/attachments/20071121/4e05e731/ISO-8859-1QCSTS_Data-Processing_Procedure_032E102E2007_11pm2EISO-8859-1Qdoc-0001.dot
More information about the Css-csts
mailing list