[Css-csts] Issues regarding the CLCW - PLOP -production
status state tables
Wolfgang.Hell at esa.int
Wolfgang.Hell at esa.int
Sun Mar 10 08:55:52 EST 2013
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.
First, the errors:
1. In the PLOP-1 table, there is no ‘bit lock acquired’ incoming
event row. This is necessary to set the bit_locked Boolean. I’ve
corrected this so that in CMM-2 the incoming event ‘bit lock acquired’
triggers the setting of bit_locked = TRUE. The event is not applicable
to any other CMM.
I agree.
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.
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.
3. In the PLOP-1 table, in the ‘rf lock lost’, ‘bit lock
dropped’, and ‘other production interruption’ rows, 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.
I agree.
4. In the PLOP-1 table, in the ‘bit lock dropped’ row, CMM-3
entry, the “transition” if bit-lock-required is ‘no’ should be to CMM-3
(that is, it should stay in CMM-3), *not* CMM-4 Preamble.
I agree.
5. In the PLOP-2 table, the only way for production status to
become operational is on the incoming event ‘bit lock acquired’. I’ve
corrected this by inserting actions in the CMM-1 entries for the
incoming events 'uplink sweep completion + 2 Way Round Trip light time'
and ' rf lock acquired' that set production status to ‘operational’
upon uplink sweep completion and rf lock acquisition (if required) if
bit lock is not required.
I agree.
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).
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 paramter
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.
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?
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.
Best regards,
Wolfgang
|------------>
| From: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|John Pietras <john.pietras at gst.com> |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|"Wolfgang.Hell at esa.int" <Wolfgang.Hell at esa.int> |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|"CCSDS_CSTSWG \(css-csts at mailman.ccsds.org\)" <css-csts at mailman.ccsds.org> |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|22/02/2013 19:24 |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|[Css-csts] Issues regarding the CLCW - PLOP -production status state tables |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|css-csts-bounces at mailman.ccsds.org |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
Wolfgang,
I’ve been looking again at the state table that combined the relationships
among the CLCW flag values, CMMs, and production status that I generated as a
result of our discussions in Cleveland. I’ve found a few errors in the
tables, but perhaps even more important, some of the actions associated with
the loss of bit lock now seem to me to be questionable. Perhaps what is
written in the table is correct and I have just forgotten the logic, or I may
have just written it down wrong in the first place.
First, the errors:
1. In the PLOP-1 table, there is no ‘bit lock acquired’ incoming
event row. This is necessary to set the bit_locked Boolean. I’ve
corrected this so that in CMM-2 the incoming event ‘bit lock acquired’
triggers the setting of bit_locked = TRUE. The event is not applicable
to any other CMM.
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.
3. In the PLOP-1 table, in the ‘rf lock lost’, ‘bit lock
dropped’, and ‘other production interruption’ rows, 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.
4. In the PLOP-1 table, in the ‘bit lock dropped’ row, CMM-3
entry, the “transition” if bit-lock-required is ‘no’ should be to CMM-3
(that is, it should stay in CMM-3), *not* CMM-4 Preamble.
5. In the PLOP-2 table, the only way for production status to
become operational is on the incoming event ‘bit lock acquired’. I’ve
corrected this by inserting actions in the CMM-1 entries for the
incoming events 'uplink sweep completion + 2 Way Round Trip light time'
and ' rf lock acquired' that set production status to ‘operational’
upon uplink sweep completion and rf lock acquisition (if required) if
bit lock is not required.
The attached revision of the state table spreadsheet includes the corrections
for the above errors.
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?
Here’s a scenario that may (or may not) be unlikely, but I think that is
possible. Say that a mission does not use CLCWs in its telemetry frames
(perhaps it determines the status of the link by mission-unique reporting
packets). By whatever means, the MOC determines that the spacecraft has lost
acquisition of the forward link and a re-sweep is necessary. If the answer to
question 2 above is that any interruption causes the uplink_sweep_completed
and rf_available flags to be set to FALSE, then treating the externally
triggered re-sweep as an ‘other production interruption’ solves the problem,
and every. But if an interruption in general does not necessarily reset
rf_available and uplink_sweep_completed, then I suggest introducing a new
incoming event, ‘uplink sweep initiated’, with the following behavior:
- In CMM-1, there is no additional behavior; it just
transitions to (stays in , actually) CMM-1;
- In CMM-2, production-status is set to ‘interrupted’;
bit_locked, uplink_sweep_completed, and rf_available are set to FALSE;
the acquisition sequence is stopped; and the transition is to CMM-1;
- In CMM-4 Preamble, production-status is set to
‘interrupted’; bit_locked, uplink_sweep_completed, and rf_available
are set to FALSE; the idle sequence is stopped; and the transition is
to CMM-1;
- In CMM-3, production-status is set to ‘interrupted’;
bit_locked, uplink_sweep_completed, and rf_available are set to FALSE;
CLTU transmission is stopped; and the transition is to CMM-1;
- In CMM-4 Trailer, production-status is set to ‘interrupted’;
bit_locked, uplink_sweep_completed, and rf_available are set to FALSE;
the idle sequence is stopped; and the transition is to CMM-1.
I propose a similar ‘uplink sweep initiated’ incoming event for PLOP-2, as
follows:
- In CMM-1, there is no additional behavior; it just
transitions to (stays in , actually) CMM-1;
- In CMM-2, production-status is set to ‘interrupted’;
bit_locked, uplink_sweep_completed, and rf_available are set to FALSE;
the acquisition sequence is stopped; and the transition is to CMM-1;
- In CMM-3, production-status is set to ‘interrupted’;
bit_locked, uplink_sweep_completed, and rf_available are set to FALSE;
CLTU transmission is stopped; and the transition is to CMM-1;
- In CMM-4, production-status is set to ‘interrupted’;
bit_locked, uplink_sweep_completed, and rf_available are set to FALSE;
the idle sequence is stopped; and the transition is to CMM-1.
I look forward to your comments.
Best regards,
John
[attachment "CMM-CLCW state machine-R2.xlsx" 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
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.
More information about the Css-csts
mailing list