[Css-csts] Issues regarding the CLCW - PLOP -production status state tables

[John Pietras]

Wolfgang,

I realized after sending the email below that I did not complete one of my comments. It was in response to your comment about checking with SLS on whether our interpretation of either not using the idle sequence of putting the same length sequence before and after the command. My recollection is that we discussed this with Greg Kazz and Ed Greenberg at one of the Colorado Springs meetings, and that they were okay with that interpretation. We can still reconfirm it if you like, but I think that we are on pretty solid ground. And, as you say, PLOP-1 has been deprecated anyway, so they might not care so much in any case.



Regarding your proposed simple solution of re-sweeping prior to every command in PLOP-1 -I don't personally have a problem with it, but we should check with other F-CLTU providers to see if that is consistent with their implementations.



As an aside - this brings up the interesting question of how long do we need to keep PLOP-1 in the F-CLTU book? Can we deprecate it now in the next version of the F-CLTU book, on the theory that an existing PLOP-1 F-CLTU user will continue to use the version of F-CLTU that they are currently using, and which presumably meets their needs? Or do we have to support the notion that an old PLP-1 mission will migrate to later versions of F-CLTU? And if we don't deprecate it now, presumably at some point all PLOP-1 users will cease to be operational. How will we know when that is?  Can/should we somehow address it in the conformance annex?



Best regards,

John



-----Original Message-----
From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: Thursday, March 21, 2013 9:48 AM
To: Wolfgang.Hell at esa.int
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org)
Subject: RE: [Css-csts] Issues regarding the CLCW - PLOP -production status state tables



Wolfgang,

I've responded below to the few items that are still in discussion, and deleted the items for which there is no disagreement. But before going onto those details I'd like to address a comment that you made that I think is very important, " PLOP-1 shall not be used for any future missions". Do you use "shall" in the requirements sense (i.e., future missions are prohibited from using PLOP-1) or in the informative sense (i.e., no future missions that you know of are planning to use PLOP-1)?



1.            If it is in the requirements sense, how was this decision made? Should PLOP-1 be deprecated?

2.            If it is only in the informative sense, is your knowledge pertinent to ESA missions only or to a larger community of missions? If it is indeed true that no Agency plans to fly any new PLOP-1 missions, and there is no good reason that any new mission would want to use PLOP-1, then perhaps PLOP-1 should be deprecated.



Again, see below for more-detailed responses to some of the items. Since the note is in plain text, I've prefaced the original text with [Original text], your comments with [WH], and my responses with [JP].



Best regards,

John



-----Original Message-----

From: Wolfgang.Hell at esa.int<mailto:Wolfgang.Hell at esa.int> [mailto:Wolfgang.Hell at esa.int]

Sent: Sunday, March 10, 2013 9:56 AM

To: John Pietras

Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>); css-csts-bounces at mailman.ccsds.org<mailto:css-csts-bounces at mailman.ccsds.org>

Subject: Re: [Css-csts] Issues regarding the CLCW - PLOP -production status state tables



John,



Sorry for not getting back to you on this matter any sooner. Anyway, I had a close look at the state tables and I have a few comments which for convenience I intersperse with your original text.



[Original note] First, the errors:

2.       In the PLOP-1 table, in the ‘trailer completes’ row, the

      bit_locked Boolean should be to FALSE before returning to CMM-1. If bit

      lock is required, bit_locked has to be reset to TRUE  by the ‘bit lock

      required’ event occurring during the subsequent CMM-2.





   [WH]  I guess your intention was to refer to the 'bit lock acquired' (not

      'bit lock required') event in the second sentence. What you suggest

      appears to work - at least so far I have not come up with a

      counterexample. What kind of bothers me is that for checking the

      transition to the desired uplink status, we evaluate the lock

      indicators in the CLCW. For the loss of bit lock, we derive the

      transition from the known CMM transition rather than reacting to the

      'bit lock dropped' event. Since the 'bit lock dropped' event is

      disregarded in CMM-1 and CMM-2, this should work. I would suggest

      however to change N/A to [ignore] since this event may well happen

      while we are in CMM-1 or CMM-2.



[JP] Good point. These have been changed to "[ignore]".





[WH] Some further points:



In the 'trailer completes' row, bit_locked shall be set to FALSE rather than TRUE as we turn off modulation (transition to CMM-1).



[JP] Thanks for catching that error. It has been corrected.



[WH] I understand from your state table that you assume that in PLOP-1 the optional idle sequence is not used at all or will be radiated before and after the CLTU proper. This assumption may well be correct, but CCSDS 232.0 is ambiguous in the respect. No managed parameter is specified that would control the absence or presence of the idle sequence nor is there a parameter that specifies the length of the idle sequence. Perhaps we should not bother too much since PLOP-1 shall not be used for any future missions, but it might be good to check with the SLS group as to make sure that our interpretation of the PLOP-1 specification matches with that group's intent.



[JP] the optional idle



[Original note] Now to the ambiguities. As specified in the current PLOP-1 table, on the occurrence of the events ‘rf lock lost’, ‘bit lock dropped’, or ‘other production interruption’, production-status is set to ‘interrupted’ and the uplink_sweep_completed and rf_available flags are set to FALSE. That implies that the uplink sweep needs to be executed again.  This makes sense for ‘rf lock lost’, but is it really true for ‘bit lock dropped’ and ‘other production interruption’?

      1.       When bit lock is lost but the RF carrier is still locked, is

      it necessary to go all the way back to a re-sweep? Is it possible that

      a mission might require bit lock but not RF availability? In this case,

      it might be reasonable to re-sweep upon bit lock loss, since that’s

      there would be no separate indication of the status of the RF carrier.

      2.       When another type of interruption (i.e., not loss of RF or bit

      lock) occurs, is it necessary to go all the way back to a re-sweep?

      Might the answer to this depend on the presence and use of RF

      availability information?





[WH] You are raising a valid point. From a logical / theoretical point of view, one should not force the complete uplink re-acquisition as long as 'only' bit lock is lost. However, before coming up with a highly optimised complex state table taking care of this condition, let's look at the conditions under which this might happen in practice:

- The station is incorrectly configured in terms of TC modulation index such that the margin in the carrier tracking loop is significantly higher than the margin we have for the data. This won't be cured by just resending the command and the optimisation in terms of not having to re-sweep does not really matter. The Configuration Control issues triggered by such event will be much more demanding than such re-sweep.

- The bit transition density in the radiated CLTU is so low that the spacecraft bit synchronizer loses lock. Obviously, such problem should not be detected in flight but rather during the RFCTs. Again, the issue is so serious that having to sweep again does not really matter.

- Inadvertently, modulation was on during the uplink sweep the spacecraft locked on the side lobe. Here one would see rf_locked = TRUE, but bit_locked remains false. In this scenario, the only way to recover is to re-sweep.

In conclusion, looking at scenarios that might provoke the condition of having RF locked, but no bit lock, they do not justify the additional complexity of a state table that would avoid the re-sweep.

As regards the 'other type of interruption', this will typically associated with some kind of equipment failure. If equipment needs to be swapped around, this generally won't be done while the carrier is up.



As regards the scenario that you have outlined and the associated additions to the state table, what you suggest looks reasonable to me. Regarding the concern expressed by your colleague working on the NASA SGSS project when in

PLOP-1 it comes to production-status = 'interrupted' due to dropped  bit lock, it appears to me that my suggestion to always require a re-sweep further to an event that causes the transition of the production-status to 'interrupted' will prevent this dead-lock situation. On user request, the provider attempts the re-acquisition of the uplink. Event 'uplink sweep completion + 2 Way Round Trip light time' in state CMM-1 will result in production-status = 'operational'. As a consequence, having unblocked the SI by CLTU-STOP, CLTU-START and CLTU-TRANSFER-DATA will be accepted by the provider. Obviously, there is no guarantee that the problem causing the loss of bit lock in the first place has been corrected and chances are that the radiation of the CLTU will fail again. I completely agree that this scenario is not adequately addressed by the present CLTU book. But before discussing how to update the book, we'll need consensus if it is acceptable that recovery from a 'bit lock dropped' requires a re-sweep.



[JP] I completely agree that we need a consensus on whether  'bit lock dropped' requires a re-sweep, or how important it is if no new mission will be using PLOP-1 (as discussed above). The concern I have is that the NASA SGSS project is taking the approach of ignoring bit lock status altogether in determining production status to avoid the "can't get back to operational" problem. Implied in this approach is that they don't intend to do a re-sweep, but I need to confirm that with them. I think that that the bigger issue for SGSS is whether any SN/SGSS users will use PLOP-1 (given the discussion above) - if they don't then it becomes a non-issue for them. I will pursue this with them separately.



[WH] Best regards,



Wolfgang






-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130321/5cc95725/attachment.html