REPORT CONCERNING SPACE

DATA SYSTEM STANDARDS

Spacecraft On-board Interface Services – Time Distribution Service

Definition

CCSDS 000.0-R-0

RED BOOK

April 2005

AUTHORITY

This Red Book has not been approved, a later version will be submitted for approval
Issue:
Date:
Location:

This document has been approved for publication by the Management Council of the Consultative Committee for Space Data Systems (CCSDS) and reflects the consensus of technical panel experts from CCSDS Member Agencies. The procedure for review and authorization of CCSDS Reports is detailed in the Procedures Manual for the Consultative Committee for Space Data Systems.

This document is published and maintained by:

CCSDS Secretariat

Program Integration Division (Code M-3)

National Aeronautics and Space Administration

Washington, DC 20546, USA

Foreword

Through the process of normal evolution, it is expected that expansion, deletion, or modification to this Report may occur. This Report is therefore subject to CCSDS document management and change control procedures which are defined in the Procedures Manual for the Consultative Committee for Space Data Systems. Current versions of CCSDS documents are maintained at the CCSDS Web site:

http://www.ccsds.org/

Questions relating to the contents or status of this report should be addressed to the CCSDS Secretariat at the address on page i.

At time of publication, the active Member and Observer Agencies of the CCSDS were:

Member Agencies

Agenzia Spaziale Italiana (ASI)/Italy.

British National Space Centre (BNSC)/United Kingdom.

Canadian Space Agency (CSA)/Canada.

Centre National d’Etudes Spatiales (CNES)/France.

Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)/Germany.

European Space Agency (ESA)/Europe.

Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.

National Aeronautics and Space Administration (NASA)/USA.

National Space Development Agency of Japan (NASDA)/Japan.

Russian Space Agency (RSA)/Russian Federation.

Observer Agencies

Austrian Space Agency (ASA)/Austria.

Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.

Centro Tecnico Aeroespacial (CTA)/Brazil.

Chinese Academy of Space Technology (CAST)/China.

Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.

Communications Research Centre (CRC)/Canada.

Communications Research Laboratory (CRL)/Japan.

Danish Space Research Institute (DSRI)/Denmark.

European Organization for the Exploitation of Meteorological Satellites (EUMETSAT)/Europe.

European Telecommunications Satellite Organization (EUTELSAT)/Europe.

Federal Service of Scientific, Technical & Cultural Affairs (FSST&CA)/Belgium.

Hellenic National Space Committee (HNSC)/Greece.

Indian Space Research Organization (ISRO)/India.

Institute of Space and Astronautical Science (ISAS)/Japan.

Institute of Space Research (IKI)/Russian Federation.

KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary.

MIKOMTEK: CSIR (CSIR)/Republic of South Africa.

Korea Aerospace Research Institute (KARI)/Korea.

Ministry of Communications (MOC)/Israel.

National Oceanic & Atmospheric Administration (NOAA)/USA.

National Space Program Office (NSPO)/Taipei.

Swedish Space Corporation (SSC)/Sweden.

United States Geological Survey (USGS)/USA.

DOCUMENT CONTROL

Document	Title	Date	Status
Time Distribution Service	April 2005	Predraft Version

CONTENTS

Section	Page

1	introduction	1-1

1.1	Purpose and scope	1-1

1.2	Document Structure	1-1

1.3	Definitions	1-1

1.3.1	Definitions from the OSI Reference model	1-1

1.3.2	Terms defined in this report	1-2

1.4	References	1-2

2	Service Concept	2-1

2.1	Overview	2-1

2.2	Use AND OPERATION of the Time Distribution Service	2-2

3	Service Definition	3-1

3.1	Provided Service	3-1

3.1.1	Wall Clock Capability (Mandatory)	3-1

3.1.2	Alarm Clock Capability (Optional)	3-1

3.1.3	Metronome Capability (Optional)	3-1

3.2	Expected Services from Underlying Layers	3-1

3.3	Service Interface	3-1

3.3.1	TDS_TIME_REQ	3-2

3.3.2	TDS_ALARM_REQ	3-2

3.3.3	TDS_CANCEL_ALARM_REQ	3-2

3.3.4	TDS_METRONOME_REQ	3-3

3.3.5	TDS_CANCEL_METRONOME_REQ	3-3

3.3.6	TDS_TIME_IND	3-3

3.4	Managed Parameters	3-4

A1	ANNEX 1 – Typical Implementation	3-1

A2	ANNEX 2 – Typical API – POSIX	3-1

introduction

Purpose and scope

This document defines the SOIS Time Distribution Service. The Time Distribution Service provides a local copy of the spacecraft on-board time which is correlated across all of the nodes implementing the service. This time can be used for example, for coarse-grained scheduling of on-board operations and for time stamping of acquired data.

The Time Distribution Service is not intended to be used as a fine-grained, multi-purpose timing mechanism for applications, e.g. it should not be used for software task scheduling.

The benefit of using the Time Distribution Service is that on-board software applications have a consistent interface to the local time source regardless of how time correlation is actually performed.

Document Structure

This document comprises three chapters:

Chapter 1, this chapter, defines common terms used within this document and lists reference documents.

Chapter 2 (informative) describes the Time Distribution Service concept.

Chapter 3 (normative) defines the Time Distribution Service, in terms of the service provided, services expected from underlying layers, and the service interface.

In addition, two informative annexes are provided.

Annex 1 describes how local time registers are implemented and how the master onboard time value is usually distributed in current spacecraft.

Annex 2 describes aspects of the POSIX API time functions which might be useful to implementer of the Time Distribution Service.

Definitions

Definitions from the OSI Reference model

The command and data acquisition service is defined using the style established by the Open Systems Interconnection (OSI) Basic Reference Model [2]. This model provides a common framework for the development of standards in the field of systems interconnection.

The following terms used in this Report are adapted from definitions given in [2]:

layer: a subdivision of the architecture, constituted by subsystems of the same rank.

service: a capability of a layer, and the layers beneath it (a service provider), which is provided to the service-users at the boundary between the service-providers and the service-users.

Terms defined in this report

For the purposes of this Report, the following definitions also apply.

Accuracy: The closeness of the agreement between the time reported by a local time source and the master on-board time source of the spacecraft.

Application: Any component of the on-board software that makes use of this service. This includes flight software applications and higher layer services.

Error bound: An indication of the notional error range of a particular time value. Larger values for the error bound indicate less accuracy in the returned time.

Precision: The smallest significant time increment that can be reported by a time source. For example a time source that reports time as minutes:seconds:milliseconds has a precision of 1ms. Note that the precision of a time source may not be the same as the resolution of that time source.

Resolution: The smallest significant time increment that can be measured by a time source. For example, a time source driven by a 1MHz oscillator has a resolution of 1μs.

Time correlation: The process of maintaining coherence between the master time source and each local time source, such that all time sources provide the same time value within some bounded uncertainty. This maximizes the accuracy of each time source with respect to the master on-board time source.

References

The following documents are referenced in the text of this Report. At the time of publication, the editions indicated were valid. All documents are subject to revision, and users of this Report are encouraged to investigate the possibility of applying the most recent editions of the documents indicated below. The CCSDS Secretariat maintains a register of currently valid CCSDS Recommendations and Reports.

[1] Procedures Manual for the Consultative Committee for Space Data Systems. CCSDS A00.0-Y-7. Yellow Book. Issue 7. Washington, D.C.: CCSDS, November 1996.

[2] Information Technology—Open Systems Interconnection—Basic Reference Model: The Basic Model. International Standard, ISO/IEC 7498-1. 2nd ed. Geneva: ISO, 1994.

[3] Information Technology - Portable Operating System Interface (POSIX) Part 1: System Application Program Interface (API) [C Language]; ISO/IEC 9945-1:1990; IEEE, 1990; ISBN 1-55937-061-0.

[4] Time Code Formats. CCSDS 301.0-B-3 Blue Book.: CCSDS, January 2002.

[5] The Open Group Base Specifications Issue 6. IEEE Std. 1003.1, 2004 Edition.

Service Concept

Overview

The Time Distribution Service provides applications with a consistent interface to a local time source that is correlated to some centrally maintained master on-board time source. The time values provided by this service might typically be used by the application to schedule some operation, such as the acquisition of an image, or to time stamp locally generated telemetry data.

The need to provide a local, correlated time source in on-board processor nodes is common to all spacecraft that have more than one processing node connected to an on-board bus or LAN. A typical architectural scenario is shown in Figure 1. Note that the Time Distribution Service is concerned only with providing the interface to the local time source. It is not concerned with the mechanism used to correlate the time between the time sources.

Figure 1 - Typical On-board Time System Architecture

In this architecture the local time sources are typically free running hardware counters accumulating seconds and sub-seconds of elapsed time. Each of these counters is driven by its own oscillator, and the absolute frequency and frequency stability of each oscillator are different in each node. The master on-board time source, the reference for on-board time for all on-board mission operations, is usually a similar free running counter driven by an oscillator with precise absolute frequency and high stability . The value provided by this time source is usually called the Mission Elapsed Time (MET).

The actual method of implementing the master on-board time source and the local time sources and the mechanisms used to correlate them is outside the scope of this document. However, Annex 1 describes a scheme that is typically used today.

This document defines a standard interface between applications hosted on each node and the local time source for that node. The scope of this document is indicated by the dashed box in Figure 1. The basic capability provided by the Time Distribution Service is the ability to read the time on demand, i.e. a ‘wall clock’ capability. Two optional extensions are also defined which reflect common requirements for on-board software systems. The first of these is an ‘alarm clock’ capability, which enables the application to request notification at a particular time. The second is a ‘metronome’ capability, which enables the application to request periodic notifications with a specified interval and starting at a particular time.

The benefit to the user is that all applications have a uniform interface to the local time source, regardless of their location on the spacecraft, and do not have to access local hardware directly. This simplifies the development of the applications and means that they can be relocated if necessary and can be re-used in other missions.

Use AND OPERATION of the Time Distribution Service

Applications should use the Time Distribution Service to obtain the time from the local time source rather than, for example, reading directly from the local elapsed time counter hardware registers. From the application software perspective this will result in applications that are more portable, easier to develop, and independent of the hardware implementations of the on-board time sources.

This time can be used, for example, for coarse-grained scheduling of on-board operations and for time stamping of acquired data.

The Time Distribution Service is not intended to be used as a fine-grained, multi-purpose timing mechanism for applications, e.g. it should not be used for software task scheduling.

The Time Distribution Service is operated using service requests and service indications passed between the service user and the service provider.

Service Definition

Provided Service

Wall Clock Capability (Mandatory)

The mandatory wall clock capability provides the user with the local on-board time on demand.

To obtain the time, the user issues a TDS_TIME_REQ primitive. The service responds with a TDS_TIME_IND primitive which contains the current local time and an indication of the accuracy and validity of this time value.

Alarm Clock Capability (Optional)

The optional alarm clock capability allows the user to register for an alarm call at a specified time.

To register for an alarm call, the user issues a TDS_ALARM_REQ primitive with the time at which the alarm call is to be issued. The service responds with a TDS_TIME_IND primitive issued at the specified time. The user may cancel a pending alarm call by issuing a TDS_CANCEL_ALARM_REQ.

Metronome Capability (Optional)

The optional metronome capability allows the user to register for a periodic indication of the time at a specified frequency starting at a specific time.

To register for a periodic indication of the time, the user issues a TDS_METRONOME_REQ primitive with the time at which the first periodic indication is to be issued and frequency at which subsequent indications are to be. The service responds with periodic TDS_TIME_IND primitives with the first indication being issued at the specified start time and subsequent indications being issued at the specified frequency. To stop the metronome, the user issues a TDS_CANCEL_METRONOME_REQ.

Expected Services from Underlying Layers

The expected service from the underlying layers is a locally maintained clock that indicates seconds and sub-seconds of monotonically increasing elapsed time. This may be expressed as an elapsed time from some specific epoch, such as the start of the mission, or may be a real-time clock.

Service Interface

The Time Distribution Service interface comprises the following primitives:

TDS_TIME_REQ

TDS_ALARM_REQ

TDS_CANCEL_ALARM_REQ

TDS_METRONOME_REQ

TDS_CANCEL_METRONOME_REQ

TDS_TIME_IND

These primitives and their associated parameters are described in the following sections.

TDS_TIME_REQ

The TDS_TIME_REQ shall be issued by the Time Distribution Service user in order to request the current time. Receipt of this shall cause the Time Distribution Service to determine the current time and return it to the application. If an answer cannot be provided by a system-specified timeout, the Time Distribution Service may return an answer with an error indication.

There are no parameters associated with this primitive.

TDS_ALARM_REQ

The TDS_ALARM_REQ shall be issued by the Time Distribution Service user in order to request a one-shot alarm at a specific time in the future.

The parameter associated with this primitive is:

Alarm_at_time.

Alarm_at_time is the time at which the user wishes to receive a time indication .

TDS_CANCEL_ALARM_REQ

The TDS_CANCEL_ALARM_REQ shall be issued by the Time Distribution Service user in order to request that a previously requested alarm call be canceled. This shall cause the cancellation of the scheduled alarm call and removal of all state associated with it

There are no parameters associated with this primitive1.

TDS_METRONOME_REQ

The TDS_METRONOME_REQ shall be issued by the Time Distribution Service user in order to request a periodic time indication at a specific time in the future and at specified intervals thereafter.

The parameters associated with this primitive are1:

First_alarm_time,

Inter_alarm_interval .

First_alarm_time is the time at which the user wishes to receive the first of a series of periodic alarms.

Inter_alarm_interval is the inter-alarm interval, in seconds and fractions of seconds, between successive alarms.

TDS_CANCEL_METRONOME_REQ

The TDS_CANCEL_METRONOME_REQ shall be issued by the Time Distribution Service user in order to request that a previously requested metronome be canceled. This shall cause the cancellation of the scheduled or active metronome and removal of all state associated with it

There are no parameters associated with this primitive1.

TDS_TIME_IND

The TDS_TIME_IND shall be issued by the Time Distribution Service in response to a TDS_TIME_REQ or a TDS_ALARM_REQ in order to deliver the current time with status and error indications.

The parameters associated with this primitive are:

Current_time,

Result,

Error_specification.

Current_time is the current time at this node, as determined by the Time Distribution Service.

Result indicates whether the request was executed correctly or not. A No_Error result implies that the time was successfully obtained and the associated Current_time parameter is valid. Other results indicate failure conditions, e.g. Timeout (the specified request could not be serviced within the managed timeout period) or Error (the time distribution service is not functioning correctly, in which case the associated Current_time parameter is not valid.

Status: The time distribution service indication may include a status parameter. The status parameter indicates one of the following states:

Error_specification indicates the error of the Current_time parameter returned in the time indication.

Managed Parameters

The Frequency is a managed parameter that indicates the rate, in Hertz, at which the Time Distribution Service is updated. A service management entity should be able to access this but it is usually not possible to update it when the clock is implemented in hardware.

The Correlation Frequency is a managed parameter that indicates the frequency at which the local clock is correlated with the central on-board time reference. A service management entity should be able to access this and should be able to update it to reflect changes in the frequency of clock correlation.

The Timeout Value is a managed parameter that determines the maximum length of time that the Time Distribution Service tries to service a TDS_TIME_REQ primitive before returning. Note that if the Time Distribution Service cannot return an answer within this time then it may return an error. A service management entity should be able to access this and should be able to update it.

The Drift is a managed parameter that indicates the stability of the local oscillator used in the local clock. A service management entity should be able to access this and should be able to update it to compensate for clock aging effects.

ANNEX 1 – Typical Implementation

How it is done now!

The local clocks are correlated to the central on-board time reference by periodically broadcasting both a time value and a synchronizing pulse that indicates exactly when that value is valid. At the instant of the synchronizing pulse each local clock is updated so that all of the clocks show the same time. Following this each local clock may drift slightly so that just before the next synchronizing pulse the variation in the values shown by each clock will reach a maximum. The frequency of the synchronizing pulse is therefore chosen to ensure this maximum variation is always within the operational limits defined by the mission.

ANNEX 2 – Typical API – POSIX

NAME

time.h - time types

SYNOPSIS

#include <time.h>

DESCRIPTION

Some of the functionality described on this reference page extends the ISO C standard. Applications shall define the appropriate feature test macro (see the System Interfaces volume of IEEE Std 1003.1-2001, Section 2.2, The Compilation Environment) to enable the visibility of these symbols in this header.

The <time.h> header shall declare the structure tm, which shall include at least the following members:

int tm_sec Seconds [0,60].

int tm_min Minutes [0,59].

int tm_hour Hour [0,23].

int tm_mday Day of month [1,31].

int tm_mon Month of year [0,11].

int tm_year Years since 1900.

int tm_wday Day of week [0,6] (Sunday =0).

int tm_yday Day of year [0,365].

int tm_isdst Daylight Savings flag.

The value of tm_isdst shall be positive if Daylight Savings Time is in effect, 0 if Daylight Savings Time is not in effect, and negative if the information is not available.

The <time.h> header shall define the following symbolic names:

NULL

Null pointer constant.

CLOCKS_PER_SEC

A number used to convert the value returned by the clock() function into seconds.

CLOCK_PROCESS_CPUTIME_ID

The identifier of the CPU-time clock associated with the process making a clock() or timer*() function call.

CLOCK_THREAD_CPUTIME_ID

The identifier of the CPU-time clock associated with the thread making a clock() or timer*() function call.

The <time.h> header shall declare the structure timespec, which has at least the following members:

time_t tv_sec Seconds.

long tv_nsec Nanoseconds.

The <time.h> header shall also declare the itimerspec structure, which has at least the following members:

struct timespec it_interval Timer period.

struct timespec it_value Timer expiration.

The following manifest constants shall be defined:

CLOCK_REALTIME

The identifier of the system-wide realtime clock.

TIMER_ABSTIME

Flag indicating time is absolute. For functions taking timer objects, this refers to the clock associated with the timer.

CLOCK_MONOTONIC

The identifier for the system-wide monotonic clock, which is defined as a clock whose value cannot be set via clock_settime() and which cannot have backward clock jumps. The maximum possible clock jump shall be implementation-defined.

The clock_t, size_t, time_t, clockid_t, and timer_t types shall be defined as described in <sys/types.h> .

Although the value of CLOCKS_PER_SEC is required to be 1 million on all XSI-conformant systems, it may be variable on other systems, and it should not be assumed that CLOCKS_PER_SEC is a compile-time constant.

The <time.h> header shall provide a declaration for getdate_err.

The following shall be declared as functions and may also be defined as macros. Function prototypes shall be provided.

char *asctime(const struct tm *);

char *asctime_r(const struct tm *restrict, char *restrict);

clock_t clock(void);

int clock_getcpuclockid(pid_t, clockid_t *);

int clock_getres(clockid_t, struct timespec *);

int clock_gettime(clockid_t, struct timespec *);

int clock_nanosleep(clockid_t, int, const struct timespec *,

struct timespec *);

int clock_settime(clockid_t, const struct timespec *);

char *ctime(const time_t *);

char *ctime_r(const time_t *, char *);

double difftime(time_t, time_t);

struct tm *getdate(const char *);

struct tm *gmtime(const time_t *);

struct tm *gmtime_r(const time_t *restrict, struct tm *restrict);

struct tm *localtime(const time_t *);

struct tm *localtime_r(const time_t *restrict, struct tm *restrict);

time_t mktime(struct tm *);

int nanosleep(const struct timespec *, struct timespec *);

size_t strftime(char *restrict, size_t, const char *restrict,

const struct tm *restrict);

char *strptime(const char *restrict, const char *restrict,

struct tm *restrict);

time_t time(time_t *);

int timer_create(clockid_t, struct sigevent *restrict,

timer_t *restrict);

int timer_delete(timer_t);

int timer_gettime(timer_t, struct itimerspec *);

int timer_getoverrun(timer_t);

int timer_settime(timer_t, int, const struct itimerspec *restrict,

struct itimerspec *restrict);

void tzset(void);

The following shall be declared as variables:

extern int daylight;

extern long timezone;

extern char *tzname[];

Inclusion of the <time.h> header may make visible all symbols from the <signal.h> header.

In certain orbits it is possible to use a time source that is correlated to an external reference time source, such as a GPS receiver, as the master on-board time source.

Mechanisms to associate particular TDS_TIME_INDs with their corresponding TDS_ALARM_REQs are implementation-specific. Similar mechanisms need to be provided by implementations to allow the TDS_CANCEL_ALARM_REQ to be associated with a particular TDS_ALARM_REQ, and a TDS_CANCEL_METRONOME_REQ to be associated with a particular TDS_METRONOME_REQ.

[6] Copyright © 2001-2004 The IEEE and The Open Group, All Rights reserved

CCSDS SOIS TIME DISTRIBUTION SERVICE

1-1

CCSDS 000.0-R-0	APRIL 2005

2-2

3-1

CCSDS SOIS Device Access Service

Red Book

2005-04-13

Stuart D. Fowell

Cotectic Ltd