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

[Chris Plummer]

Stuart,

At a quick glance these all look like familiar primitives that we have
discussed many times in the past. Based on those discussions, I have a few
comments:

Firstly, the WAIT_FOR_TIME.REQUEST/INDICATION pair (horrible names by the
way, let's start using proper ISO naming conventions for the primitives can
we?) are an obvious extension to the basic GetTimeReq/Ind pair, and turn the
simple wall clock into an alarm clock. This has been proposed many times in
the past and we have always decided not to include it because a) we did not
have a strongly expressed user requirement for it, and b) because it implies
a bit more complexity in the service implementation. Looks like you got
somebody to express a firm user requirement for this, which therefore
justifies the additional complexity in an implementation.

However, I'm not sure that it is appropriate for every implementation of the
service in every node. I suspect that there are plenty of users who really
do only require wall clock functionality. So I think we need to offer this
as an optional capability.

While we are looking into this, we should also revive the periodic call
capability that has been discussed in the past. Here the user requests a
periodic call at some predefined (low) frequency, for example a signal at
every minute on the minute. Most users who want the WAIT_FOR_TIME type
capability are also interested in this periodic signal. However, specifying
the primitives and details of the capability provided can be a little bit
tricky, and is often contentious. In other words this can be a can of worms
and we should be careful about whether we really want to open it.

Secondly, the management primitives that you are suggesting. In my view,
these do not square at all with the time distribution service that I at
least have in mind. This would suggest that there are still some fundamental
clarifications to be made with respect to this service, or that I have
completely misunderstood your intention with this. In a nutshell my
objection is that adding these primitives means that the user can adjust the
time that the local time distribution entity provides, and this just
violates the whole idea of distributing a correlated reference time in the
first place. So I think we need to have some serious discussion about
whether these primitives belong in the service or not.

Cheers,
        Chris.

-----Original Message-----
From: sois-tcoa-bounces at mailman.ccsds.org
[mailto:sois-tcoa-bounces at mailman.ccsds.org] On Behalf Of
Stuart.Fowell at scisys.co.uk
Sent: 21 March 2005 18:26
To: sois-tcoa at mailman.ccsds.org
Subject: [Sois-tcoa] Time Distribution Service - additional primitives?


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

----------------------------------------------------------------------------
----------------------------

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