<font size=2 color=#424282 face="Calibri">Dear John,</font>
<p><font size=2 color=#424282 face="Calibri">I have been thinking a bit
about your options for timestamping of parameters delivered via a GET return.</font>
<p><font size=2 color=#424282 face="Calibri">In my view the spirit of Mauro
Pecchioli’s RID was that, actually, each individual CSTS parameter
data gets its own generation time tag, rather than the complete PDU and
all its contained parameter data. The reason for this was, that the parameter
data may be useful in the context of troubleshooting analyses implying
correlation with spacecraft telemetry data.</font>
<p><font size=2 color=#424282 face="Calibri">However, the answer to MPs
RID should be that it would be very complex to provide a timestamp to each
and every parameter of a ground station, for the following reasons:</font>
<p><font size=2 face="Calibri">- </font><font size=2 color=#424282 face="Calibri">for
every parameter there are various elements involved in its sampling: from
the basic sensor/instrument, to the relevant application in charge of it
( e.g. an Antenna’s Front-end Controller) and to the Station Manager
application. In this scenario, who would be in charge of generating the
proper time stamp of the parameter? The value may be very different depending
on who in the chain will generate it ( and therefore it may become unreliable)</font>
<p><font size=2 face="Calibri">- </font><font size=2 color=#424282 face="Calibri">as
a consequence of that, ground station parameters can only to a minor extent
be used for troubleshooting of mission or spacecraft anomalies. At ESA,
the application in charge of monitoring and control of the Ground Station
(the Station Computer) does not have the capability to handle history data
( i.e. data with an associated time stamp). It only has the real-time picture
of the Stations situation at any given point in time. In case troubleshooting
of operational anomalies is required, other means are normally used ( e.g.
log messages, events, etc).</font>
<p><font size=2 color=#424282 face="Calibri">In the light of the above,
I spoke to Mauro Pecchioli, and he agreed that there is no point in requesting
such timestamping of individual parameters. Also, I outlined there is no
point in having a single timestamp for the whole GET return PDU, as this
adds very little information. Mauro agrees to that. </font>
<p><font size=2 color=#424282 face="Calibri">So, I would say that the RID
can be rejected (or “withdrawn by the author” I am not sure which
is most appropriate). Mauro is in copy. He may confirm if this is ok with
him.</font>
<p><font size=2 color=#424282 face="Calibri">Please let me know if this
ok with you.</font>
<p><font size=2 color=#424282 face="Calibri">Kind regards,<br>
Margherita</font>
<p>
<p><font size=2 face="sans-serif">-------------------------------------------------------------<br>
Margherita di Giulio<br>
Ground Station Back-end Section (HSO-GIB)<br>
European Space Agency ESA/ESOC<br>
Robert-Bosch-Str. 5<br>
D-64293 Darmstadt - Germany<br>
Tel: +49-6151-902779<br>
e-mail: Margherita.di.Giulio@esa.int<br>
<br>
</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">John Pietras <john.pietras@gst.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"CCSDS_CSTSWG
(css-csts@mailman.ccsds.org)" <css-csts@mailman.ccsds.org>,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">19/11/2014 17:38</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">[Css-csts] FW:
Monitored Data CSTS RID "Generation Time for GET"</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">css-csts-bounces@mailman.ccsds.org</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>CSTSWG colleagues --<br>
You have already received Mr. Pecchioli's reply (copied below) to my questions
regarding his suggestion to add a Generation Time parameter to the GET
Return. He states that for troubleshooting purposes it may be necessary
to have the measurements timestamped to within an accuracy of a few milliseconds.
He also goes on to say that if multiple parameter values are queried via
a single GET invocation, then each value may have to have an individual
timestamp. Here are my thoughts on the matter.<br>
<br>
Regarding the need for a timestamp with accuracy to within an few milliseconds,
if we agree that the MD-CSTS should be applicable to his troubleshooting
use case, then we can add an appropriate generationTime parameter. <br>
<br>
However, I don't believe that his assertion that each queried parameter
has its own timestamp in the Return necessarily holds true. We said in
our meeting last week that the assumption is that each parameter value
that is returned is captured at the time that the GET Return is generated.
In other words, every value in the GET Return would have been sampled no
more than some few (TBD) milliseconds before the time that the GET Return
was created. I would make that requirement explicit in the procedure specification
(although at this point I'm not exactly sure what the best way would be).
A follow-on question is, should the MD-CSTS specification set the
specific limit, or simply say that it is an implementation parameter that
must be documented in the PICS Proforma (and then add it to the PICS Proforma)?<br>
<br>
If we do decide to add the generationTime parameter to the GET Return,
should that be only an MD-CSTS extension of the Cyclic Report procedure,
or should it be a general capability of the CSTS SFW Cyclic Report procedure?<br>
<br>
Finally, I have been thinking about the statement that we made that the
MD-CSTS shouldn't require a second Red Book review. However, we are considering
adding this new capability, and we have already agreed to modify the Cyclic
Report procedure to allow on-change-only reporting. These are significant
technical changes, and I don't know that we can justify the "no Red-2
Agency review" claim. <br>
<br>
I welcome your comments on Mr. Pecchioli's reply and my proposed response.
If you have comments, I would like to ask you to provide them (please copy
the CSTSWG) by 1 December so that we can come to a final resolution
of this RID in a timely manner. Thank you.<br>
<br>
Best regards,<br>
John<br>
<br>
-----Original Message-----<br>
From: Mauro.Pecchioli@esa.int [</font></tt><a href=mailto:Mauro.Pecchioli@esa.int><tt><font size=2>mailto:Mauro.Pecchioli@esa.int</font></tt></a><tt><font size=2>]
<br>
Sent: Wednesday, November 19, 2014 4:47 AM<br>
To: John Pietras<br>
Cc: CCSDS_CSTSWG (css-csts@mailman.ccsds.org)<br>
Subject: Re: Monitored Data CSTS RID "Generation Time for GET"<br>
<br>
Dear Mr. Pietras,<br>
<br>
thanks for contacting me. The main reason why I raised the suggestion to
add the Generation Time in the GetReturn is to harmonise the definition
of this PDU with the TransferData PDU and avoid unnecessary differences
in the associated processing of parameter data on the receiving side. However,
you raise an important point about the 'time-stamping' accuracy of parameter
samples. When using this data for standard monitoring (e.g. range checking,
live visualisation, etc.), I believe that an accuracy in the order of few
seconds is adequate. But I assume that the parameter data may also be useful
in the context of troubleshooting analyses implying correlation with spacecraft
telemetry data, in which case I believe that an equivalent accuracy in
the time-stamping is required. It should be noted that we typically require
an accuracy of a few milliseconds for the spacecraft telemetry parameter
samples time-stamping. This may imply that each individual CSTS parameter
sample is associated to its own generation time, rather than the complete
PDU and all the contained parameter data.<br>
<br>
I hope this helps<br>
<br>
Best regards<br>
<br>
M. Pecchioli<br>
<br>
<br>
<br>
<br>
<br>
From: John Pietras <john.pietras@gst.com><br>
To: "mauro.pecchioli@esa.int" <mauro.pecchioli@esa.int>,<br>
Cc: "CCSDS_CSTSWG (css-csts@mailman.ccsds.org)"<br>
<css-csts@mailman.ccsds.org><br>
Date: 17/11/2014 21:15<br>
Subject: Monitored Data CSTS RID "Generation Time for
GET"<br>
<br>
<br>
<br>
Mr. Pecchioli,<br>
Hello, I’m John Pietras. I’m the book editor for the CSTS Monitored Data
Service Red Book. Thank you for reviewing the book.<br>
<br>
One of your RIDs, titled “Generation time for GET”, stated:<br>
“I suggest to add the generationTime parameter also for the GET Return
PDU (similarly to the TRANSFER-DATA PDU). This is useful for the receiving
side to know when the parameter value has been sampled.”<br>
<br>
The CSTS Working Group discussed this RID and decided that we need a bit
more information about your intentions for the recommended changes before
we could decide on how to proceed.<br>
<br>
Here is a little bit more background information that will hopefully help
us come to a mutual understanding.<br>
<br>
In the RID, you use the TRANSFER-DATA as an example of an invocation carrying
a generationTime. However, there is a difference between the generation
time of a TRANSFER-DATA invocation and a GET return, in that (in some cases,<br>
anyway) a TRANSFER-DATA invocation may be stored in a Recording Buffer,
and so the generation time is disjoint from the actual delivery time. In
contrast, the GET return is always sent in immediate response to the GET
invocation, so the generation time of the parameters can be assumed to
be the time of receipt, minus some time for transmission through the underlying
communications network. Furthermore, since the GET returns are all delivered
in-sequence by the underlying TCP connection, there is no question as to
the sequencing of the returns.<br>
<br>
Therefore, adding a generationTime parameter to the GET return would be
needed only if the generation time that can be estimated from the receipt
time (i.e., normally within a second or two) is insufficiently accurate
for an Agency’s (or Mission’s) purposes. Is there is a requirement to
know the generation time with greater accuracy than within 2 seconds of
the receipt time of the return?<br>
<br>
The CSTS WG is considering extending the GET return set of parameters
to include a single generationTime parameter that applies to all values
carried in the return . Note that this would be the generation time of
the GET return itself; it would provide no indication of the actual freshness
of each of the parameters being reported. The assumption is that all values
being reported are current values.<br>
<br>
If we were to add a generationTime parameter to the GET return, it would
have to be with the understanding that all values being returned in the
GET return are current as of the time that the GET return is generated
and sent. That is, it would not be possible (without major reworking of
not only the MD-CSTS but the CSTS Framework as a whole) to have measurements
taken at various times sitting and waiting to be retrieved via the GET
operation. If a measurements is “stale” by any appreciable amount of
time, it negates the usefulness of having the generationTime in the GET
return.<br>
<br>
So, to summarize:<br>
1. To your understanding, is
it sufficient to know that the time<br>
of a measurement to within 2 seconds of its true generation
time? If<br>
so, then no change to the MD service would be required.<br>
2. If it is not sufficient, we
could put a single generationTime<br>
parameter in the GET return. This generationTime would
apply to all<br>
values in the return, which implies that all values
contained in the<br>
return are sampled essentially instantaneously at
generationTime. Would<br>
that suit the purposes for which you envision the
generationTime<br>
parameter?<br>
<br>
Thank you in advance for your help in refining and resolving this RID.<br>
<br>
Best regards,<br>
John Pietras<br>
Principal Engineer<br>
GST, Inc.<br>
7855 Walker Drive, Suite 200<br>
Greenbelt, MD 20770<br>
240-542-1155<br>
<br>
This message and any attachments are intended for the use of the addressee
or addressees only.<br>
The unauthorised disclosure, use, dissemination or copying (either in whole
or in part) of its content is not permitted.<br>
If you received this message in error, please notify the sender and delete
it from your system.<br>
Emails can be altered and their integrity cannot be guaranteed by the sender.<br>
<br>
Please consider the environment before printing this email.<br>
<br>
<br>
<br>
--<br>
BEGIN-ANTISPAM-VOTING-LINKS<br>
------------------------------------------------------<br>
<br>
NOTE: This message was trained as non-spam. If this is wrong, please
correct the training as soon as possible.<br>
<br>
Teach CanIt if this mail (ID 01NhlUPGG) is spam:<br>
Spam: </font></tt><a href="https://filter.gst.com/canit/b.php?i=01NhlUPGG&m=d995a131a932&c=s"><tt><font size=2>https://filter.gst.com/canit/b.php?i=01NhlUPGG&m=d995a131a932&c=s</font></tt></a><tt><font size=2><br>
Not spam: </font></tt><a href="https://filter.gst.com/canit/b.php?i=01NhlUPGG&m=d995a131a932&c=n"><tt><font size=2>https://filter.gst.com/canit/b.php?i=01NhlUPGG&m=d995a131a932&c=n</font></tt></a><tt><font size=2><br>
Forget vote: </font></tt><a href="https://filter.gst.com/canit/b.php?i=01NhlUPGG&m=d995a131a932&c=f"><tt><font size=2>https://filter.gst.com/canit/b.php?i=01NhlUPGG&m=d995a131a932&c=f</font></tt></a><tt><font size=2><br>
------------------------------------------------------<br>
END-ANTISPAM-VOTING-LINKS<br>
<br>
_______________________________________________<br>
Css-csts mailing list<br>
Css-csts@mailman.ccsds.org<br>
</font></tt><a href="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts"><tt><font size=2>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts</font></tt></a><tt><font size=2><br>
</font></tt>
<br><PRE>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.
</PRE>