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

[Richard Schnurr]

Hi All,

Some thoughts:

The way this is sometimes dealt with is to use a network message that 
triggers some hardware or software action (Task/state change).  Other 
actions or availability of data may be keyed to these "network" messages as 
well.

The scheduled service of TCONS is the only hope of implementing 
functionality like this in a standard way.  Thus the primitives for this 
service need to be associated or at least traced with the TCONS scheduled 
service.

The accuracy of these types of things vary significantly depending on the 
implementation.  Thus the accuracy and repeatability of such a service will 
be Bus/Lan/Implementation specific.

In general time is not always the driver.  For example a state machine that 
implements some functionality can also be implemented using this type of 
service with asynchronous network messages.

Thus time is just one driver for things like this.

Another reason TCONS scheduled service and time service should be 
considered together.

Rick

At 06:24 AM 3/22/2005, Stuart.Fowell at scisys.co.uk wrote:

> > > 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
>
>
>
>
>
>
>
>
>_______________________________________________
>Sois-tcoa mailing list
>Sois-tcoa at mailman.ccsds.org
>http://mailman.ccsds.org/mailman/listinfo/sois-tcoa

Richard G Schnurr Jr
Chief Architect
Electrical Systems Center
Applied Engineering and Technology Directorate
NASA GSFC Code 560.0
Greenbelt MD 20771

(301)-286-1852