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

[Scott Burleigh]

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.
> 
> 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
> 
> 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
> 
> Comments?

Stuart, I think these are all service primitives that are likely to be needed on a flight system.  But now that we enumerate them, I think a broader issue comes up.

I believe it has always been a core principle of CCSDS to recommend the adoption of existing standards wherever possible, recommend adoption of existing standards as adapted for the space applications domain where necessary, and develop new standards only when there is no alternative.  Do we really need to develop a new standard service specification for the time distribution service?  Could SOIS simply Recommend instead that all agencies standardize on, say, the POSIX Real Time Extensions (POSIX 1003.1b)?  Or are there capabilities that we know are needed that no existing API standard addresses?

Scott