[Css-csts] A#01-0510S : review of the parameter list provided byESA

Tue Oct 12 09:15:15 EDT 2010

John,

Better late than never - at last I have a bit of time to work on the
monitored data again and in that context let me respond to your
questions/comments.

1. I have used the asterisk to identify those parameters that are static as
they reflect the configuration of station equipment as applicable to the
given mission. One could therefore argue that there is no point in monitoring
these parameters as their setting can safely assumed to be known to the
client mission. On the other hand, in real world operations I have seen
myself that under certain condition parameter settings are changed and due to
different culture and jargon in different agencies, there is always a chance
of misunderstanding. Therefore, although at first glance monitoring of these
parameters looks redundant, I personally would like to have the actual
setting reported via the MD service.

2. You are correct. In case of high rate telecommanding, we won't have a
subcarrier, but the TC symbol stream will directly modulate the carrier.
Therefore I concur that to have this in a 'neutral place, I should probably
move it to Data Interface Status. And for 'coherent with data clock' I need
to find a better word. What I actually meant is that the the subcrarrier is
16 kHz and the data clock can be expressed as 4000 / 2 exp n with n = 0 .. 9.

3. You are correct, but it is not uncommon that PLOP-1 is used in combination
with leaving the unmodulated subcarrier on between commands ('always on'). My
intent was to use 'always off' for the high rate case where no subcarrier is
used. But based on your comment I realize that this would be under the wrong
heading in that case. I will think about how to restructure the spreadsheet..

4. I'm not sure if that is the best possible term. It is ESA jargon for a
ranging system where a tone is used for the actual measurement of the
turn-around time, while a combination of codes is used for ambiguity
resolution. In the (very) old days, we also had pure tone ranging systems
(with the major tone for the measurement as such and the minor tones for
ambiguity resolution. The CCSDS PN ranging system is an example of a ranging
system fully based on codes. In ESA we therefore refer to a system that uses
both tones and codes as a hybrid system.

5. A very good point. For now, I did not try to address any hierarchical
structure, cardinality and the like, but tried to identify the parameters as
such. At least from an ESA perspective, thinking about who is going to look
at the monitored data I think we shall avoid redundancy and report production
parameters relevant to several SLE SIs only once. I have some doubt if the SI
specific parameters shall really be made accessible via the MD service. The
SLE client is interested in these parameters, but they are accessible using
the SLE service proper.

6. As indicated under 5., I would consider removing SI specific parameters
that are accessible using the SLE service proper. For the others, I would not
want to constrain the access method a priori, as what is needed will be
driven by the mission scenario.

Best regards,

Wolfgang

  From:       "John Pietras" <john.pietras at gst.com>                                                                                             

  To:         <Wolfgang.Hell at esa.int>                                                                                                           

  Cc:         css-csts at mailman.ccsds.org                                                                                                        

  Date:       17/08/2010 17:12                                                                                                                  

  Subject:    RE: [Css-csts] A#01-0510S : review of the parameter list provided byESA                                                           

  Sent by:    css-csts-bounces at mailman.ccsds.org                                                                                                

Wolfgang,
I have a few comments about the monitored parameter list as documented
in (Monitored parameters list- CNES comments WH reply.doc).

1. Many parameters have an asterix (*) aftere their names. What does the
asterix signify?

2. The PLOP and "coherent with data clock" parameters are grouped under
the Uplink Subcarrier Status category. However, it is my understading
that data (and therefore the PLOP) can be modulated onto the carrier as
well as the subcarrier. Should not the PLOP (and I assume the "coherent
with data clock" parameter) also be allowed to be assiociated with the
uplink carrier? (NOTE - It is for situations such as this that the
strawman breakout of functional resources has a Symbol Stream functional
resource. All parameters of the Symbol Stream resource are then
associated with whatever carrier or subcarrier is being data-modulated.)

3. Under the Uplink Subcarrier Status, the PLOP parameter has values
"always on" and "always off". What are these, since they are not
CCSDS-defined PLOPs?

4. I'm showing my ignoreance here - what is hybrid ranging?

5. The various SLE transfer services report the status of a number of
production parameters associated with those transfer services. As
written in the draft monitored parameters list, these production
parameters are grouped with the SLE transfer services. This raises a
question in my mind - is it better to (a) associate these production
parameters with the individual transfer service instances (in which case
there may be redundant reports of the same values), or (b) report the
production parameters once (e.g., associated with the symbol stream or
physical channel) and somehow relate the transfer service isntances with
their respective symbol streams/physical channels?

6. Is this list of parameters supposed to be ones that can be cyclically
reported, notified on change, queriable, or all classes? For parameters
associated with SLE transfer services, the list of monitored parameters
includes parameters that are notified via the ASYNC-NOTIFY operation,
periodically reported via the STATUS-REPORT operation, and one-time
retrieved via the GET-PARAMETER operation. The FOP State, for example,
is retrievable via the GET-PARAMETER operation but not via the
STATUS-REPORT operation.  Would it make sense to annotate in the
parameter list to list the expected "access method" (e.g.,
cyclically-reported, notification on change of value (e.g., for states
or other enumerated types), of via information query)?

Best regards,
John

_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts