TR: [Css-csts] A#01-0510S : review of the parameter list provided by
ESA
Lassere Francois
francois.lassere at cnes.fr
Mon Aug 16 08:44:24 EDT 2010
Dear Wolfgang,
You will find here below some answers and comments from Jean-Michel Roquebert (network operations centre). The comments are in blue in the text of the mail and there are also some answers/comments in the parameter list file.
Best regards.
François
> > <<Monitored parameters list- CNES reply to WH.doc>>
>
>
> -----Message d'origine-----
> De : Wolfgang.Hell at esa.int [mailto:Wolfgang.Hell at esa.int] Envoyé : mercredi 11 août 2010 15:57 À : Lassere Francois Cc : css-csts at mailman.ccsds.org; css-csts-bounces at mailman.ccsds.org
> Objet : Re: [Css-csts] A#01-0510S : review of the parameter list provided by ESA
>
>
> Dear Francois,
>
> Thank you for your feedback regarding the candidate monitored parameters that at last I manage to look at. For specific issues, I have inserted my response into the table proper. In addition, I should like to share with you some more general considerations as follows:
>
>
> You are absolutely correct that the table contains quite a number of parameters that are also accessible via the SLE (or possibly CSTS) service interface. At first glance it therefore appears redundant to make these parameters also accessible via a dedicated monitoring service. But the key question here is who will be the user of these monitored parameters. Even if I disregard for now a true cross support scenario, within ESA the SLE client is the Flight Control Team. Their expertise is primarily on the spacecraft side and to a lesser extent on ground stations. The team in charge of the operating the stations is much more interested in a number of these 'SLE parameters' than the actual SLE user and therefore even internal to ESA it makes sense to have these SLE parameters also accessible via the separate path of a monitored data service.
>
> When it comes to actual cross support, this becomes even more important as being responsible for the provisioning of services to an external client, I want to have know exactly what is going on and therefore need the capability to closely monitor my SLE providers although I'm not the user of the SLE services. Granted, as this is internal to an agency one can come up with proprietary monitoring capabilities, But if I can have the same monitoring regardless of the station being operated by ESA or another agency, such uniform capability is of advantage.
>
> For the above reasons I think that what John had originally proposed is useful in real world operations and therefore I have incorporated these parameters following John's suggestions.
>
> [Jean-Michel Roquebert] : I agree. We, at the CNES Network Operations Centre, already have access to these SLE parameters through our ground station's monitoring and control system but you're right, having access to the same parameters from external ground stations is of advantage even if we do not directly operate them. However, this should be limited to dynamic parameters and should not carry configuration information that was already validated during tests.
>
> You are also correct that it should not be necessary to have parameters monitored whose values are the result of mutually agreed configurations. On the other hand, I have been in situations on console where due to a combination of language and terminology issues it was very difficult to figure out via the voice loop what the actual configuration looked like and what one could possibly do in terms of corrective action. Therefore, although the need to monitor these parameters will be rare, they might be very useful in critical situations.
>
> [Jean-Michel Roquebert] : I understand your point but I still believe that mutually agreed and validated by testing parameters, from the space-to-ground interface specification or following the realization of RF compatibility tests, data flow tests> ...> do not need to be monitored. It's the responsability of the service provider to verify and garantee the correct configuration of the ground station's equipment. I agree that in some rare but critical situations it may be helpful for the service user> to monitor these parameters (for double verification or just to avoid difficult voice exchanges) and to propose configuration changes but in that case the list of monitored parameters could even be longer, might be mission dependent and will result in a higher complexity of the monitoring service user and higher bandwidth utilization requirements. Therefore, our position remains that the monitoring service should be used to transfer dynamic parameters reflecting the status of the ground stations equipment but not its configuration.
>
>
> Best regards,
>
> Wolfgang
>
> (See attached file: Monitored parameters list- CNES comments WH reply.doc)
>
>
>
>
> From: "Lassere Francois" <francois.lassere at cnes.fr>
>
> To: <css-csts at mailman.ccsds.org>
>
> Date: 01/06/2010 16:36
>
> Subject: [Css-csts] A#01-0510S : review of the parameter list provided by ESA
>
> Sent by: css-csts-bounces at mailman.ccsds.org
>
>
>
>
>
>
>
> Dear CSTS WG colleagues,
>
> Please find below attached the CNES review of the monitored data parameter list provided by ESA with some comments or questions.
> Best regards.
>
>
> François
> [attachment "Monitored parameters list- CNES comments.doc" deleted by Wolfgang Hell/esoc/ESA] _______________________________________________
> Css-csts mailing list
> Css-csts at mailman.ccsds.org
> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Monitored parameters list- CNES reply to WH.doc
Type: application/msword
Size: 318464 bytes
Desc: Monitored parameters list- CNES reply to WH.doc
Url : http://mailman.ccsds.org/pipermail/css-csts/attachments/20100816/6d711cbe/Monitoredparameterslist-CNESreplytoWH-0001.doc
More information about the Css-csts
mailing list