[Css-csts] SLE Monitoring Service JPL Procedure Note - Y.Doat Comments

[Charles J Ruggier]

Dear Yves,

Thank you for providing review comments on the Monitoring Service Procedure 
document.  This document has  been revised and presently undergoing final 
internal review at JPL.  Efforts have been made to clarify the procedure as 
it relates to a service type rather than as a data retrieval process that 
is available through existing operations.  It  is not our intention to 
exclude the use of the THROW-EVENT and STATUS-REPORT operation as the 
primary mechanisms for requesting and receiving the monitor data.  The idea 
is to use the generic elements of  the THROW-EVENT and STATUS-REPORT 
operations, with the assumption that the specifics of the monitoring 
service request can be properly handled with the SET and GET 
parameters.  Conceptually, the monitoring service can be structured on top 
of the Toolkit using existing generic operations.

It is expected that the revised monitoring service procedure document will 
address the concerns that you have identified below.  I will also take 
another look at the control directive procedure to determine how to merge 
it with THROW-EVENT procedure.  Hopefully,  these projects will be 
completed and reviewed before the end of this week.

I have included some additional responses to you comments in your e-mail 
message below.

Best Regards,
Charles

At 01:29 AM 8/26/2005, Yves.Doat at esa.int wrote:
>Dear Charles,
>
>Thank you for your monitoring procedure.
>I looked at it and I have a few comments.
>
>Main comments:
>    A new operation is proposed "MONITOR DATA REQUEST". The new operation you
>    propose can only serve a Monitoring service purpose and cannot be generic.
>    In my opinion we should extract the parameters that are generic and map it
>    to one of the existing operation, i.e. THROW-EVENT.
>    Note: I support the comment provided by CNES on 03.08.2005

The text in the procedure document "Monitor Data Request" has been changed 
to "Monitoring Service."   This new service will utilize the existing 
generic operations and the GET/SET parameters (as stated above) .


>    The operation supporting the Send Monitor Data is missing. The "Status
>    Report" procedure seems to cover the need of the Monitoring message.
>    Note: I support the comment provided by CNES on 03.08.2005

Existing data transfer mechanisms can be used to send the monitor 
data.  The specific details of the status reporting can be set through the 
GET/ SET parameters, which in turn set the STATUS-REPORT 
operational  parameters.


>    Performance Data is a monitoring parameter on the QoS of its own. I 
> don’t
>    see what brings this information. In my opinion it is the role of the
>    Service Management to monitor the QoS. In any case this is specific
>    parameter to the proposed monitoring service and should not appear in the
>    Toolkit.

Agree.  The Service Management will monitor the QoS and interact with the 
Utilization Manager and Complex Manager to request/retrieve performance 
data, as specified by the monitoring service for a single instance delivery 
or periodic delivery of the monitor data.  The details of this interactive 
behavior needs further analysis and discussion.


>    Section 1.3: In case of exception the service provider should abort the
>    connection. All the proposed procedures follow the CCSDS SLE API approach.
>    In case of syntax errors or semantic errors, the initiator shows a big
>    behaviour problem.
>    Recovery of such malfunctions might be very difficult: how to
>    re-synchronise? How to deal with the next incoming messages that may have
>    been issued prior to the treatment of the sent exception?

Agree.  The service provider should abort the connection when exception 
occurs.  This will be reflected in the revised procedure.


>    Control procedure: The UML diagram seems very similar to the THROW-EVENT
>    UML diagram. Would you have time to look at the THROW-EVENT procedure and
>    identify what are the differences? Would you see a possibility to merge
>    the two approaches? Will you have time to prepare the corresponding
>    procedure?

Since only the monitor data procedure was requested as an action item, the 
control directive UML diagram  serves only as a preliminary concept of the 
control procedure.  However, the feasibility of merging it with the 
THROW-EVENT operation should be explored and evaluated as soon as possible 
as indicated above.


>Best regards
>
>Yves
>OPS-GIB
>ESA/ESOC
>Robert-Bosch str.5
>D-64293 Darmstadt
>Tel.: (+49)-6151-902288
>_______________________________________________
>Css-csts mailing list
>Css-csts at mailman.ccsds.org
>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts

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