A device is described which provides the value of date coordinated universal time (date UTC) to the JPL Network Operations Control Center, Real Time (NOCC-RT) facility. The NOCC-RT is the real time portion of the NOCC upgrade task. The time scale is generated in the NOCC-RT clock processor; however, there is a continuous reference to UTC, as realized by the National Institute of Standards and Technology and transmitted by Earth orbiting satellites. An important functional design requirement is the 99.9 pct. availability

Clements, P. A.

Kelley, M. J.

Lopez, J. G.

English

NASA Technical Reports Server

TDA Progress Report 42-100 February 15, 1992 
3 
An Assembly to Provide a Time Reference for the JPL 
Network Operations Control Center, Real-Time 
P. A. Clements and J. G. Lopez 
Communications Systems Research Section 
M. J. Kelley 
Communications Systems Research Section and Telos Corporation, Pasadena. California 
I I  
This article describes a device which provides the value of date-coordinated uni- 
versal time (date UTC)'to the JPL Network Operations Control Center, Real-Time 
(NOCC-RT) facility. The NOCC-RT is the real-time portion of the NOCC upgrade 
task. The time scale is generated in the NOCC-RT clock processor; however, there 
is a continuous reference to UTC, as realized by the National Institute of Stan- 
dards and Technology and transmitted by Earth-orbiting satellites. An important 
functional design requirement is the 99.9-percent availability. 
1. Introduction 
The NOCC-RT clock processor (NCP) is a device which 
supplies the value of date-coordinated universal time (date 
UTC) to  the JPL Network Operations Control Center, 
Real-Time (NOCC-RT) facility. The NCP is a separate de- 
vice from the other hardware in NOCC-RT. The software 
in the NCP is a separate program set, designated NOCC- 
RT clock reader (NCR), which is located in programmable 
PROM's on a single-board computer. The entire device is 
designated a DSN assembly of the NOCC-RT Frequency 
and Timing (NFT) Subsystem. The NFT is one of the 
seven subsystems which compose the NOCC-RT facility. 
1 
"The reading of a specified time scale. Note that the date can be 
conventionally expressed in years, months, days, hours, minutes, 
seconds, and fractions thereof.. . ."[1] 
NOCC-RT requires that the value of date UTC be avail- 
able with a precision of 1 msec and an accuracy of 10 msec 
within the program sets which compose NOCC-RT. The 
availability of the value of date UTC at the output of the 
NCP is required to be 99.9 percent. This time scale must 
be generated from a 1-MHz signal originating a t  a cesium- 
beam frequency standard located a t  the JPL  Standards 
Laboratory (JSL). To ensure that the output is to the re- 
quired accuracy and precision, it is referenced to the UTC 
generated at  the National Institute of Standards and Tech- 
nology UTC (NIST) in Boulder, Colorado. 
Access to  UTC (NIST) is via time transmissions from 
two Geostationary Operational Environmental Satellites 
(GOES), which are operated by the U.S. Department of 
Commerce. UTC can be realized with a precision and 
accuracy of 100-psec using a GOES timing receiver. The 
21 4 
https://ntrs.nasa.gov/search.jsp?R=19920015074 2020-03-17T12:08:41+00:00Z
accuracy of the NCP was designed to be 1 msec. This 
allows the 10-msec accuracy requirement of NOCC-RT to 
be met even with the reduction of precision and accuracy 
in the computer system. Tests have shown the value of 
date UTC within NOCC-RT to be within 5 msec of UTC 
(NET).  
Availability was the most difficult design requirement to 
meet. The design approach taken was to use redundancy 
as well as a diversity of sources for the value of date UTC: 
Both the East and West GOES are used, in concert with a 
local cesium clock. The value of date UTC is received from 
the three sources, then compared. If two or three agree, 
that date is accepted; if all three disagree then the date of 
the local clock is the date accepted, but fault flags are set 
in the status bytes of the output to indicate uncertainty. 
These flags correspond to the lights on the front panel of 
the computer. 
II. Design Process 
A. NOCC-RT Frequency and Timing Subsystem 
The design of the NFT was derived from functional 
These requirements were combined with 
requirements for the remaining six NOCC subsystems 
which compose NOCC-RT to develop the functional de- 
sign document (FDD) for NOCC-RT. The FDD was writ- 
ten as a task document and, as such, contained the design 
for all of NOCC-RT in that particular design phase. 
The NCP is largely a hardware device but with sig- 
nificant software. Because the NCR is a program set in 
a piece of hardware separate from the rest of NOCC-RT, 
a separate ensemble of design documents was developed 
starting with the software requirements document (SRD). 
B. NOCC-RT Clock Processor 
After being separated from the rest of NOCC-RT and 
at  the start of the software requirements analysis phase, 
the NCP design was divided into hardware and software. 
The hardware design followed the traditional DSN design 
practice, which culminates in a hardware transfer agree- 
ment. At the same time, documents3 were developed for 
the software, starting with the SRD and ending with the 
software transfer agreement. 
Network Operations Control Center Subsystems Functional Re- 
quirements: Frequency and Timing Monitor Subsystem (1991- 
1995), JPL D-5423 (internal document), Jet Propulsion Labom 
tory, Pasadena, California, January 15, 1989. 
JPL Software Management Standards Package, JPL D-4000 (inter- 
nal document), Jet Propulsion Laboratory, Pasadena, California, 
December 1988. 
The hardware and software aspects of the design were 
remerged primarily in the software test plan and p r e  
cedures. The NCP was tested as a DSN assembly and 
the results recorded in the software test report. An in- 
teresting example of this remerging was the section of the 
software test results report which proved the availability 
requirement had been met. The availability analysis dealt 
only with the hardware part of the NCP. However, the re- 
sulting report is a compact and complete verification that 
the NCP meets the hardware and software functional re- 
quirements assigned to it. 
After the NCP was tested in place, it was connected 
to the NOCC-RT computers. The entire NCP was then 
included in the NOCC-RT integration testing, which was 
at  the NOCC upgrade task level. 
111. Hardware Configuration 
The NCP consists of two GOES receivers, a time-code 
translator/generator (TCT), a computer with a front panel 
containing status lights and a fiber-optic interface for the 
antenna cables. Figure 1 shows the NCP installed in the 
NOCC-RT cabinet a t  the JPL Space Flight Operations Fa- 
cility (SFOF). Figure 2 shows a schematic representation 
of the NCP. Notice that the NCP receives a parallel time 
code from the three sources and sends a serial time code 
to NOCC-RT. 
The two GOES receivers are configured using front- 
panel switches. The East and the West GOES signals are 
selected by a toggle switch. The location of the receiver is 
entered using a thumb-wheel switch. The satellite’s signals 
are received by antennas located on the roof of a building 
which is adjacent to SFOF. The output of the receivers is 
a parallel time code with millisecond resolution. A serial 
status message is also sent to  the NCP. The status mes- 
sage is used to build the status bytes, which are included 
in the serial time code output from the NCP. 
The TCT can properly function in two different ways 
in the NCP: It can translate a serial time code to a parallel 
time code or it can generate a parallel time code from a 
source of 1 MHz. It is configured to accept a 1-MHz signal 
which is originated at  the JSL. The JSL provides time and 
frequency service anywhere at  JPL  usually using a directly 
hard-wired GOO-R phone line. In the case of the NCP, the 
signal is proximately provided by a 1-MHz distribution 
system internal to SFOF. Again, the output of the TCT 
is a parallel time code, with a format identical to that of 
the GOES receivers and the stability of a cesium frequency 
standard. 
21 5 
The computer is a Multibus I configuration with a CPU 
board, three 1/0 boards for the parallel time input and sta- 
tus input from the GOES timing receivers, and a special 
board to operate the front-panel status lights. A commer- 
cially available chassis is used, with new front and back 
panels added. Figure 3 shows the computer with the front 
panel opened up. The CPU board is on top. The next 
three boards are 1/0 to  the time-code sources and the 
bottom board operates the front panel. 
The front-panel status lights provide the same informa- 
tion that is sent in the status bytes of the output message. 
Green lights indicate correct functioning while the red in- 
dicate fault. The indicators are divided into two groups. 
The first group shows the condition of the inputs to the 
NCP. For example, if the value of date from the satellite 
receiver is unreliable because of a loss of signal, a red light 
will switch on. The second group indicates the condition 
of the output of the NCP. The NCP will accept the date 
UTC, but if it judges the date to  be inaccurate, a red light 
will switch on. 
There are instructions on the front panel and inside the 
front door so that installation or replacement of equipment 
can be accomplished without the installation manual. The 
switch positions on the front of the receivers are given on 
the computer’s front panel. The cabling diagram is affixed 
to the inside of the front door. 
Because of SFOF electrical conductivity requirements, 
part of the GOES antenna cable was replaced with fiber- 
optic cable. Special conversion modules were designed, 
constructed, and used in the antenna line. The config- 
uration is shown in Fig. 4. The optical fiber provides a 
nonconductive path through the boundary of SFOF and 
still allows normal operation of the GOES receiver. 
IV. Software Structure4 
Being able to read a clock and report the value of date 
to a computer requires knowing the amount of time that 
each task takes to complete. Also, the NCR is required to 
respond frequently and quickly to requests for date UTC. 
These requirements led to  the decision to write the soft- 
ware in assembly language. This was not a difficult prob- 
lem because the program was small. The use of assembly 
language also allowed the application program to handle 
For a complete description of the software structure, refer to Soft- 
ware Specification Document (Volume I), N O C C  Frequency and 
Timing Subsystem, NOCC Clock Reader Software, NOI-5450-OP- 
A / 1 . 0  (internal document), Jet Propulsion Laboratory, Pasadena, 
California, 24 January 1992; vol. 2 in press. 
21 6 
its own interrupts, which in turn allowed precise control of 
the amount of time needed to read the clocks. 
The millisecond counter measures the time between 
clock-reading cycles. The accuracy and precision require- 
ments to allow the NCP to read a clock only in response 
to  a request were too complex because the NCP must be 
ready to send the value of date immediately. Instead, the 
NCP reads the clock on a regular schedule, and when a re- 
quest for the value of date UTC comes in, the reading cy- 
cle stops, and the NCP sends out the most recent value of 
date UTC with the accumulated time-interval value from 
the millisecond counter. 
NOCC-RT wanted the time mark to  be at the end of 
the message, and not at  the beginning, where it is usually 
placed. So the time required to  transmit the message, 
plus about 10 milliseconds, is added to  the value of date. 
The accepted value of date is sent; then a pause occurs to 
monitor the millisecond counter until it reads the value of 
the date sent. The time mark is then sent on the exact 
date UTC. 
The four major tasks of the NCP are to read the time 
code from the three clocks, get the status information from 
the two GOES receivers, count milliseconds, and send the 
value of date UTC to NOCC-RT upon request. 
The two GOES receivers and the time-code translator/ 
generator all produce time code with the same format, a 
parallel binary code. The three outputs are read in rapid 
succession, then compared in a “majority-vote” algorithm 
to  obtain a value of date UTC. 
Status information on the condition of the date value 
from the GOES receivers is obtained from serial ports on 
the receivers. There is no status information from the 
time-code translator/generator . 
The millisecond counters are started, one of them at 
each reading of the clocks, when the clocks are read. This 
allows an interpolation of the value of date UTC between 
clock readings. The clocking pulse interrupts the micro- 
processor every millisecond to update the counter. The 
total run time of the millisecond counter is from 20 to 
30 msec, which is the clock-reading-cycle time. 
Lastly, the NCP services the request for the value of 
date UTC from the NOCC-RT facility. At the end of each 
clock-reading cycle, the user-request lines are polled to de- 
termine if a request has come in. When a request is rec- 
ognized, a value-of-date-UTC message is formatted and 
transmitted to NOCC-RT . 
V. Interface Between the NCP and NOCC-RT 
The interface between the NCP and the NOCC-RT 
computer is a standard RS-232 format. At the time the 
original design work was done, it was not known how close, 
physically, the NCP would be to the NOCC-RT comput- 
ers. It was decided to provide for a fiber-optic output of the 
date information. By using a 25-pin-electric to twefiber- 
optic-cable interface, the value of date UTC can be trans- 
mitted up t o  two kilometers from the NCP. This means 
that the value of date UTC can be made available any- 
where at JPL  with a precision and accuracy of 1 msec. Be- 
fore the NCP was installed in SFOF, the value of date UTC 
was provided to operational NOCC-RT in SFOF from the 
development laboratory, located over 300 m distant, by 
using fiber-optic cables. 
The value of date UTC is requested by NOCC and the 
NCP responds with the date message. The date message 
is different than the one usually encountered. The mes- 
sage begins with the value of date (to the millisecond); 
then there are two bytes of status information. The date- 
UTC message is valid at the time that the last byte of the 
message is sent. 
Requests for the value of date UTC are from two 
NOCC-RT computers. Each computer makes a request 
about once every five seconds. The NCP first sends the 
value of date UTC and then provides the date mark. The 
value of date UTC does not necessarily coincide with the 
second tick, but can be any millisecond of the second. 
VI. Installation 
The NCP is installed on the third floor of SFOF. The 
adjacent building (180) has an unobstructed view of the 
geostationary satellites, so i t  was decided to install the 
antennas on that building’s roof. The antenna cables were 
then run down cable ducts from the roof, under the road, 
into the SFOF basement, and up to the third floor. 
While the installation was taking place, SFOF engineer- 
ing staff decided to  not allow the running of cables capa- 
ble of conducting electricity into the building. A redesign 
was then started to replace the coaxial antenna cable with 
fiber-optic cable. The coaxial cable had already been laid 
from the roof to the second floor of the adjacent building, 
so it was decided to leave that cable in place and install a 
fiber-optic-to-coaxial converter box in the telephone closet 
on the same floor. This box converts the intermediate fre- 
quency and local oscillator signals for the GOES antenna 
from electrical t o  optical. The antenna signal was routed 
through fiber-optic cable to the basement of SFOF and 
then to the third floor. Another fiber-optic-teelectrical 
converter box was installed as a part of the NCP hard- 
ware to convert the antenna signal back to electrical so 
that it could be input to the receiver. 
VII. Performance 
The NCP meets all of the functional requirements as- 
signed to it by the NOCC-RT FDD. The frequency at 
which the value of date can be received has been tested 
for up to  17 times per second with an accuracy and pre- 
cision of 1 msec. Each request is answered with a value 
of date UTC and a set of validation flags in the status 
bytes. The value of date UTC includes the proper inser- 
tion of leap seconds, as is required in the UTC time scale. 
Furthermore, notification of approaching leap-second and 
leap-year events is provided by the flag bits in the status 
bytes. 
All the acceptance tests were done after the NCP 
was installed in SFOF. The test equipment, including a 
portable cesium clock to check the accuracy of the value 
of date UTC, was brought to the NCP to complete the 
tests. 
The NCP will service two computers, as it was designed 
to do. IIowever, there is no reason it could not service more 
computers. With tlie fiber-optic distribution of the value 
of date UTC upon request, a large system of intercon- 
nected computers could stay synchronized by referencing 
the date UTC at selected points, thus avoiding the prob- 
lem of reduction of the precision and accuracy of the value 
of date as it is passed through interconnecting computer 
structures . 
VIII. Conclusions 
The NCP is a reliable source for date UTC. The value 
of date UTC is validated by the NCP and it is a true UTC 
with all of the leap-second adjustments included. 
217 
Ref ere nce 
[l] Recommendations of the CCIR,  1990 (Also Resolutions and Opinions), Vol. VII, 
Standard Frequencies and Time Signals, CCIR, Geneva, Switzerland, p. XIV, 
1990. 
218 
ORtGlNAt PAGE 
BLACK AND WHITE PHOTOGRAPH 
Fig. 1. The NOCC-RT clock processor assembly installed In Its cabinet. 
219 
GOES 
SATELLFE 
ANTENNA 
GOES 
SATELUTE 
ANTENNA 
JPL 
STANDARDS 
LAB 
NCP 
PARALLEL TIME CODE 
RCVR 1 
I I  I 
PARALLEL TIME CODE y NCR is"" 4 
DERIVED 
STATUSDATA TIME CODE) - 
PARALLEL TIME CODE - I 
NOCC-RT 
COMPUTER 
Fig. 2. Schematic diagram of the NOCCRT clock processor, showing the interconnections between the 
receivers, the time-code translatorlgenerator, and the NOCCRT clock reader. 
ORlG!3U.4L FPCZ 
WACK AND WHITE Pi-iGi irGKAPh 
Fig. 3. The NOCC-RT clock reader chassis with the front panel opened, showing the 
computer and input/output boards. 
220 
C'?!?INAL PAGE 
BLACK AND WHITE P ZOTGGRAPH 
Fig. 4. A GOES receiver assembly. 
22 1 


An assembly to provide a time reference for the JPL Network Operations Control Center, Real-Time

Abstract

Similar works

Full text

Available Versions

NASA Technical Reports Server