[Css-csts] Another CLCW-PLOP-production status issue

[Wolfgang.Hell at esa.int]

John,

I have tried to cover this point in my previous email on the PLOP state
machines. I look forward to your comments on the matter.

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 23:09                                                                                                                                      |
  >------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >------------------------------------------------------------------------------------------------------------------------------------------------------|
  |[Css-csts] Another CLCW-PLOP-production status issue                                                                                                  |
  >------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by:   |
|------------>
  >------------------------------------------------------------------------------------------------------------------------------------------------------|
  |css-csts-bounces at mailman.ccsds.org                                                                                                                    |
  >------------------------------------------------------------------------------------------------------------------------------------------------------|





Wolfgang,
Shortly after sending my previous message today, I received another message
from a colleague working on the NASA SGSS Project. Many of the questions that
I’ve raised about the interrelationships among the CLCW flags, CMMs, and
production status have been triggered by inquiries from SGSS personnel. This
latest one has to do with what my colleague perceived to be the inability to
recover from a production interruption due to loss of bit lock in PLOP-1. His
concern is that if bit-lock is required, if it is ever lost, production
status -> ‘interrupted’ and receipt of CLTUs is inhibited. If no CLTUs can be
received, there will be no CLTUs to trigger the transmission of the
acquisition sequence  that would re-establish bit lock to clear the
interrupted status.

My response to him was that by invoking the STOP operation the blocking of
CLTU transfer would be removed. However, I realized that I was also assuming
that the source of the interrupted status would be cleared, thus enabling a
subsequent START to be successful and CLTU-TRANSFER-DATA invocations to flow.
However, there’s nothing that explicitly states that. The closest thing to
addressing this situation is the NOTE under 3.7.2.3 (c) of FCLTU B-3 , “The
user can unblock the service instance by invoking a CLTU-STOP operation.
After the condition causing the ‘production interrupted’ event is corrected,
the provider notifies the user by means of a ‘production operational’
notification.  The user can resume the transfer and radiation of CLTUs after
successfully invoking CLTU-START.” Strictly speaking, FCLTU
production/provision can’t “know” that the condition causing the interruption
has been cleared because the means of ascertaining that (sending bits on the
uplink and seeing the resultant bit lock in the CLCW) is inhibited.

If the intent is to have loss of bit lock interrupt service only long enough
to force blocking of the CLTU-TRANSFER-DATA operations, maybe we don’t in
fact want to call this an interruption of production – maybe we just want to
state that TRANSFER-DATA is blocked.  Or maybe we can treat it as an impulse
interruption that occurs and clears almost immediately, just for the sake of
generating the appropriate notifications.

How should this work?

Best regards,
John
 _______________________________________________
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.