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

[Chris Plummer]

Let's try to put this all into perspective.

Time distribution is a service that will be part of the SOIS portfolio. Time
management is a capability that is usually provided to maintain coherence
between the onboard master clock and the ground, or between several
cooperating spacecraft, and is not within the scope of SOIS, however we
might consider providing informative text about it (personally I'm against
this though).

Can we also be clear about the purpose of the time distribution service,
i.e. what users should be doing with the time that it provides. In my view,
this distributed time is typically used for scheduling onboard operations
and for tagging data. For example, the distributed time might be used to
trigger the release of a time tagged telecommand, or to trigger an onboard
mode change, or for the security guys it might be used to synchronise crypto
key changes. In terms of time tagging, it might be used to generate the time
tag in a telemetry packet, or in the case of payload instruments to mark
when an observation was made. The SOIS distributed time SHOULD NOT be used
for scheduling software tasks or processes....this would be bad engineering.

The question of responsibility and criticality is basically this. If a user
has requested an alarm call or periodic time notification, and then uses
this to signal the start of some critical operation then there is an implied
transfer of responsibility onto the time distribution service. This may
affect the criticality of the time distribution service implementation, and
we may wish to avoid this.

Finally, at the risk of sounding uncle-ish, some implementation experience.
A time distribution capability has been a requirement on every spacecraft
that I have been involved with, and I've checked back through several specs
for different spacecraft today. Basically, the process used has always been
the same, although the detailed implementation has to take account of the
underlying hardware capabilities. That process is to distribute a time value
in a special packet or bus message, usually called a chronogram, and then to
distribute an accurately timed reference pulse which indicates when the
chronogram time is valid. This is analogous to the old talking clock: "at
the first stroke it will be 6pm precisely"...pip, pip, pip. Although they
can be combined, the chronogram distribution and reference pulse
distribution are logically distinct steps in the process.

The real problem is the distribution of the reference pulse. On a truly
synchronous bus like the ESA OBDH bus, we used to use one of the slot
synchronisation markers which was guaranteed to be aligned at one second
intervals as the reference pulse, and the chronogram was cleverly
sub-commutated in one of the OBDH broadcast bits. Damien Maeusli, former
chair of SOIF actually developed a standard chip set implementing this for
ESA spacecraft!

On 1553 things are a bit more tricky because this is not a truly synchronous
bus. The reference pulse could be derived from a message synch marker
because ultimately the bus controller has control over when messages are
transmitted, but in practice most spacecraft opt to bus a separate signal
around the spacecraft, usually this is the PPS signal.

On a CAN bus again it is technically possible to transmit a synch marker
through the bus because of the lossless CDMA mechanism used on CAN coupled
with the priority based medium access control. Some terrestrial systems use
this approach, but in my experience all the spacecraft implementations I
have seen have taken the sensible way out and used a separately bussed PPS
signal to distribute the synch marker.

On any communication bus that is not truly synchronous, or does not have a
cast iron way of accurately controlling the transmission time of a message,
external provision of the synch marker is the only option available.

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: 22 March 2005 12:25
To: sois-tcoa at mailman.ccsds.org
Subject: RE: [Sois-tcoa] Time Distribution Service - additional primitives?


> > 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