[Sois-tcoa] Time Distribution Service - additional primitives?

[Abhijit Sengupta]

Please see in-line comments.

Abhijit


At 3/21/2005 09:26 AM, Stuart.Fowell at scisys.co.uk wrote:

>Hi guys,
>
>I'm currently doing some modelling work on TCOAS services indirectly for
>ESA. Because of the lack of available SOIS specifications at the time of
>requirements capture, Astrium have had a go at specifying some themselves,
>from which I'm then modelling possible implementations.
>
>As far as Time Distribution is concerned, they have, beyond the
>TIME.REQUEST and TIME.INDICATION, the following primitives (in two broad
>categories):
>
>1. Use of OBT:
>
>WAIT_FOR_TIME.REQUEST         request to receive notification at a certain
>time event
>       parameters might include:
>             request token
>             class of event          absolute or relative time, periodic
>event
>             value             absoluate time, relative time or period
>WAIT_FOR_TIME.INDICATION            indication of the outocme of the
>request for notification at a certain time event
>TIME_EVENT.INDICATION         indication that time event has occurred
>       parameters might include:
>             request token
>
>I originally questioned the need for the need for WAIT_FOR_TIME.REQUEST as
>this felt like the domain of an RTOS. However, I can see the need for an
>event triggered by a timeout associated with the OBT, e.g. a time-tiggered
>command.

I also question the need for this service. If an application A1 running on 
a processor P1 needs a signal - which is basically an alarm -  when the 
processor P2 reaches a time T in P2's clock, such a signal can be generated 
at P1 by setting an timer interrupt by knowing the time correlation between 
P1 and P2. I agree that a reasonably accurate (whatever that means) 
correlation between the two processors are needed and this can be achieved 
through some period TIME.REQUEST with high periodicity (like once every 
hour or so).

In fact if this proposed service is present and too many applications use 
them at the same time, the resulting congestion might affect the accuracy 
adversely.


>2. Managing OBT:
>
>SET_TIME.REQUEST              request the modification of the Onboard Time
>(OBT).
>       parameter:
>             time              new OBT
>SET_TIME.INDICATION           indication of outcome of request to modify
>OBT

I thought SET_TIME kind of request is needed only after a processor 
power-on kind of situation. Again, assuming a reasonable estimate of tome 
correlation I do not see the need for SET_TIME except for a processor 
power-on condition.

>CONFIGURE_TIME_SYNC.REQUEST   request to enable/disable
>auto-synchronisation
>       parameters might include:
>             enable/disable
>             master                  indicate local clock is the master (or
>not)
>             protocol          select auto-synchronisation protocol
>             period                  period of auto-synchronisation protocol
>(this may be fixed for particular implementations/protocols)
>CONFIGURE_TIME_SYNC.INDICATION      indication of the outcome of the
>configuration of the auto-synchronisation
>
>RESYNCED_TIME.INDICATION      indication that the local OBT has been
>modified due to either SET_TIME.REQUEST or auto-synchronisation
>       parameter:
>             time              new OBT
>SYNC_LOST.INDICATION          indication that auto-synchronisation with a
>master clock has been lost

Did not we decide not to attempt time synchronization - rather use time 
correlation instead?

>Comments?
>
>Stuart
>
>--------------------------------------------------------------------------------------------------------
>
>Stuart D. Fowell
>Senior Consultant
>SciSys Ltd
>Clothier Road
>Bristol, BS4 5SS, UK
>
>Tel: +44 (0)117 971 7251
>Fax: +44 (0)117 971 1125
>Email: stuart.fowell at scisys.co.uk
>--------------------------------------------------------------------------------------------------------
>
>
>
>_______________________________________________
>Sois-tcoa mailing list
>Sois-tcoa at mailman.ccsds.org
>http://mailman.ccsds.org/mailman/listinfo/sois-tcoa



________________________________________________
All personal and professional opinions in this email are my own
and do not represent, in any way, the opinion or policy of JPL
________________________________________________