[Sois-tcoa] Time Distribution Service - additional primitives?
Stuart.Fowell at scisys.co.uk
Stuart.Fowell at scisys.co.uk
Tue Mar 22 05:21:37 EST 2005
> 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?)
Sorry, just followed Keith & Scott's lead :o)
> 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.
OK
> 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.
In my requirements, the class of Periodic Event corresponds to this - "A
frequency to wake up cyclic task or sequencer". To my mind, this should
have been a separate primitive as it has different characteristics, not
least of which it is not a one-shot time event, so presumably there would
need to be the ability to suspend and/or cancel 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.
Actually, this is a general point about all SOIS services. These primitives
are similar in status to updating routing tables for example. There is a
clear distinction between user and management primitives. Management
primitives should only be available to a certain class of user, i.e. are
priviledged operations. In addition, I'm sure there are different ways in
which these can be set, perhaps using a protocol rather than a user
primitive.
For TDS the issue is that we are only correlating/synchronising time within
a spacecraft, not between different spacecraft. However, even master clocks
do drift with time and so there is a requirement to adjust the spacecraft's
onboard time to correct this.
Similarly the failure of correlation/synchronisation mechanisms should
trigger FDIR algorithms, hence this service should be able to raise an
event indicating this failure.
--------------------------------------------------------------------------------------------------------
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
--------------------------------------------------------------------------------------------------------
"Chris Plummer"
<c.plummer at skynet To: <Stuart.Fowell at scisys.co.uk>, <sois-tcoa at mailman.ccsds.org>
.be> cc:
Subject: RE: [Sois-tcoa] Time Distribution Service - additional primitives?
21/03/2005 18:22
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
More information about the Sois-tcoa
mailing list