[Sois-tcoa] Time Distribution Service - additional primitives?
Stuart.Fowell at scisys.co.uk
Stuart.Fowell at scisys.co.uk
Tue Mar 22 06:24:34 EST 2005
> > 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.
> [Chris]
> Yes, this is part of that can of worms. You need a start and stop pair to
> run this service. You also get into issues of responsibility and
criticality
> that can get very contentious.
> [sirhC]
Hmmm.
Responsiblity. Are you talking about a separation of the creation of the
periodic timer and the recipient of the period time event? If I was writing
an API (yes, I know Chris, but like lots of people I like to try to
envisage an API then abstract backwards to a service primitive), I'd have a
primitive to create the periodic timer that took a callback handler for the
time event as an argument and returned a handle for subsequent management.
The callback handler would receive the handle when invoked to allow it to
distinguish different events. Other primitives would allow the suspension
and deletion of the periodic timer, identified by its handle. The failure
of the periodic timer would be a separate indication primitive (I generally
prefer to separate out normal behaviour and failures).
Criticality. Can you elaborate what the issues are here, as you see them?
> > 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.
>
> [Chris]
> I think you might have missed the point I was trying to make. Yes, sure,
> management primitives are distinct from service invocation
primitives....I
> hope we are all comfortable with that one by now. However, the point I
was
> trying to make is that your proposed primitives are fiddling with the
value
> of the time, which is not at all the business of this service. This is a
> time distribution service, not a time management service!
>
> We have had meetings in the past with the navigation people about time
> management (i.e. space-ground correlation, or correlation between
proximal
> spacecraft) and while we all agree that there is a need for a time
> management service, it has never been within any one groups domain. I
guess
> that now it fetches up in the MOIMS domain.
> [sirhC]
>
> For TDS the issue is that we are only correlating/synchronising time
within
> a spacecraft, not between different spacecraft.
>
> [Chris]
> Let's try and settle on a terminology here. The time distribution service
is
> "distributing" time so that each node has a local time reference that is
> "correlated" with an onboard reference time. "Synchronised" is a word
that
> doesn't belong here.
> [sirhC]
>
> However, even master clocks
> do drift with time and so there is a requirement to adjust the
spacecraft's
> onboard time to correct this.
>
> [Chris]
> Yes, but this should not be done through a time distribution service. It
> might be done through a time management service.
> [sirhC]
OK, I'm happy to separate out a time management and a time distribution
service. The time management service is responsible for the setting,
adjustment etc of the "master" on-board time. The time distribution service
is responsible for the distribution of the "master" on-board time to
on-board applications, potentially across a spacecraft network. So there
are three functional entities:
1. Master on-board time clock [probably want to settle terminology here].
This is entirely implementation
specific, however is a necessary functional entity, because this is the
manner in which the two services
below interact.
2. Time management service, that sets etc the master on-board time clock.
The SetTimeReq/Ind primitives belong
with this service.
3. Time distribution service, that also uses the master on-board time clock
but only as a reader. The
GetTimeReq/Ind and WaitForTimeReq/Ind etc primitives belong here.
Only the Time distribution service is in scope of SOIS. However, the Red
Book for TDS should describe this division of responsibility to as to avoid
raising comments such as in this thread.
> Similarly the failure of correlation/synchronisation mechanisms should
> trigger FDIR algorithms, hence this service should be able to raise an
> event indicating this failure.
>
> [Chris]
> Failure of the correlation mechanism in the time distribution service
will
> result in the local time drifting. The TDS entity is responsible for
> detecting this, and indicates this to the service user in the validity
flag
> (or whatever quality parameters we define) in the time indication
primitive.
> It is, in my view, wrong to raise an event to the user when this happens
> because, a) the user may not be interested and certainly doesn't want to
be
> disturbed unnecessarily, and b) because the user can't do anything about
it
> anyway. If an event is raised at all, it might be raised through the
> management interface so that local node FDIR is informed.
I entirely agree, it should be raised through the management interface - I
should have been more explicit in saying this!
> The one exception to this is where the service is providing a time
triggered
> call back to the user (either one shot or periodic). Here we would need
to
> raise an indication that informs the user that we are unable to guarantee
> the provision of the service because the correlation function is not
> working. So that is another one of those worms wriggling out!
> [sirhC]
Again, I agree. See earlier comments.
--------------------------------------------------------------------------------------------------------
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?
22/03/2005 11:00
Comments in line below.
-----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: 22 March 2005 11:22
To: sois-tcoa at mailman.ccsds.org
Subject: RE: [Sois-tcoa] Time Distribution Service - additional primitives?
> 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.
[Chris]
Yes, this is part of that can of worms. You need a start and stop pair to
run this service. You also get into issues of responsibility and
criticality
that can get very contentious.
[sirhC]
> 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.
[Chris]
I think you might have missed the point I was trying to make. Yes, sure,
management primitives are distinct from service invocation primitives....I
hope we are all comfortable with that one by now. However, the point I was
trying to make is that your proposed primitives are fiddling with the value
of the time, which is not at all the business of this service. This is a
time distribution service, not a time management service!
We have had meetings in the past with the navigation people about time
management (i.e. space-ground correlation, or correlation between proximal
spacecraft) and while we all agree that there is a need for a time
management service, it has never been within any one groups domain. I guess
that now it fetches up in the MOIMS domain.
[sirhC]
For TDS the issue is that we are only correlating/synchronising time within
a spacecraft, not between different spacecraft.
[Chris]
Let's try and settle on a terminology here. The time distribution service
is
"distributing" time so that each node has a local time reference that is
"correlated" with an onboard reference time. "Synchronised" is a word that
doesn't belong here.
[sirhC]
However, even master clocks
do drift with time and so there is a requirement to adjust the spacecraft's
onboard time to correct this.
[Chris]
Yes, but this should not be done through a time distribution service. It
might be done through a time management service.
[sirhC]
Similarly the failure of correlation/synchronisation mechanisms should
trigger FDIR algorithms, hence this service should be able to raise an
event indicating this failure.
[Chris]
Failure of the correlation mechanism in the time distribution service will
result in the local time drifting. The TDS entity is responsible for
detecting this, and indicates this to the service user in the validity flag
(or whatever quality parameters we define) in the time indication
primitive.
It is, in my view, wrong to raise an event to the user when this happens
because, a) the user may not be interested and certainly doesn't want to be
disturbed unnecessarily, and b) because the user can't do anything about it
anyway. If an event is raised at all, it might be raised through the
management interface so that local node FDIR is informed.
The one exception to this is where the service is providing a time
triggered
call back to the user (either one shot or periodic). Here we would need to
raise an indication that informs the user that we are unable to guarantee
the provision of the service because the correlation function is not
working. So that is another one of those worms wriggling out!
[sirhC]
----------------------------------------------------------------------------
----------------------------
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
_______________________________________________
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