Get direct links to references, BibTeX extraction and comments on all arXiv papers with: Librarian
The [OAO-C (Orbiting Astronomical Observatory C, aka OAO 3)](http:/...
The Landsat is the longest-running program for acquisition of satel...
The International Ultraviolet Explorer (IUE) was an observatory sat...
OSS-1 was the payload of the third shuttle flight - the STS-3, laun...
This represents a great shift. The NSSC-1 started the trend away fr...
The Multimission Modular Spacecraft (MMS) was a spacecraft designed...
Cosmic rays and high energy electromagnetic radiation can cause a l...
Diode-transistor logic (DTL) was a class of circuits that preceded ...
Low power was a very common restriction when designing for space. T...
The NSSC-1 did not support floating point.
The Grand Tour Mission was a NASA mission that would have sent two ...
XDS stands for Xerox Data Systems
HAL-S (High-order Assembly Language - Shuttle) was a language devel...
**Attitude control** is about establishing the orientation of a bod...
SPECIAL SECTION
Paul Schneck
Guest Editor
DEVELOPMENT AND APPLICATION
OF NASA's FIRST STANDARD
SPACECRAFT COMPUTER
To provide the autonomy needed by low, earth-orbiting satellites, NASA's
first standard on-board processor requires changing only interfacing
hardware from mission to mission.
CHARLES E. TREVATHAN, THOMAS D. TAYLOR, RAYMOND G. HARTENSTEIN,
ANN C. MERWARTH, and WILLIAM N. STEWART
As a means of providing the autonomy needed for
many of NASA's low, earth-orbiting satellites. NASA's
first Standard Spacecraft Computer (NSSC-1) has
evolved from the on-board processor that was flown as
an experiment on the Orbiting Astronomical Observa-
tory C (OAO-C} in 1972. As the computer was applied
to other missions, implementation improvements were
made. Even before the launch of OAO-C, a program
was initiated to improve reliability and reduce size and
weight. The result of the program was that the ad-
vanced on-board processor (AOP) was flown on the
Landsat B and C missions where it was used to aug-
ment the stored command capability and perform on-
board telemetry limit checking. On the International
Ultraviolet Explorer (IUE), the AOP performed attitude-
control computations; on OSS-1, it provided the stored
commands necessary for efficient instrument control.
In 1974, the computer became a NASA standard space-
craft component. The NSSC-1 has flown on two mis-
sions: the Solar Maximum Mission and Landsat D. Its
functions include stored command processing, attitude
control, limit checking and corrective action, and
backup telemetry. The NSSC-1 is scheduled to fly on
four missions that will be launched in the 1980s. One of
the major benefits of the central on-board computer is
that significantly different mission requirements can be
met through changes to only flight software.
This article was written in 1983. Since then, two prospective missions men-
tioned in the article have been accomplished. Landsat-D prime was launched,
and the Solar Maximum Observatory
was successfully
repaired.
© 1984 ACM 0001-0782/84/0900-0902 75¢
BACKGROUND
From the National Aeronautics and Space Administra-
tion's (NASA's) infancy in the late 1950s, unmanned
low earth-orbit spaceflight missions have rapidly in-
creased in sophistication to meet the needs of an eager
scientific community. As early as the mid 1960s, the
growth in science objectives required that space ob-
servatories accommodate elaborate instruments and in-
clude stored command processors to provide efficient
and complex on-orbit operations. This level of auton-
omy proved so successful that mission and operations
managers desired almost immediately to use on-board
computers as a means of improving observatory per-
formance even more. Increases in spacecraft autonomy
were motivated by the need to
extend stored command capability from 2 or 3
hours to up to 24 hours,
automatically modify on-board observations based
on detected phenomena,
provide monitoring of instruments and equipment
when not in view of the ground and either gener-
ate summary messages for transmission to ground
during station contact or command the observatory
to a safe mode in the event of anomalous condi-
tions, and
provide the flexibility in orbit to work around po-
tential failures of mission-critical functions.
In order to meet these needs, the Goddard Space
Flight Center (GSFC) developed a medium-scale, gen-
eral-purpose computer that was flown as an "expert-
902 Communications of the ACM September 1984 Volume 27 Number 9
Special Section
ment" on the Orbiting Astronomical Observatory C
(OAO-C) in 1972. This first computer was referred to as
the on-board processor (OBP). As the computer was ap-
plied to other missions, implementation improvements
were made and its functional assignments on user ob-
servatories were expanded. The first notable example
of this was the processor's additional performance of
attitude-control computations on the International Ul-
traviolet Explorer (IUE). A later example was a more
general-purpose application on the Multimission Modu-
lar Spacecraft (MMS). In this case, the computer pro-
vided the autonomy and flexibility necessary for the
MMS to support a variety of solar, stellar, and earth-
referenced missions without requiring redesign of
spacecraft hardware. With a history of flight experience
and multimission application, the machine, now known
as the NSSC-1, was selected as NASA's first Standard
Spacecraft Computer in 1974.
During early definition of the OBP, several hardware
and software requirements were defined to provide for
flexibility through low-power, radiation-resistant hard-
ware, an expandable, nonvolatile memory, and an
"easy to use" support software system. As other re-
quirements evolved, the method of interfacing the com-
puter with the user observatory proved to be the most
important factor in achieving the desired flexibility. By
interconnecting the computer with the spacecraft com-
mand and telemetry system as shown in Table I, an
extension of the Operations Control Center was essen-
tially placed on board.
Required command reliability was ensured by the
use of self-test software that had to be successfully exe-
cuted before distribution of commands. All computer-
user missions launched to date have made use of this
relatively simple interface. The IUE and MMS applica-
tions required an additional input and output to allow
the computer to directly address any telemetry channel
for acquisition of data at a higher rate needed for atti-
Acronyms and Special Terminology
AOP: Advanced on-board processor
ATCP: Absolute time command processor
DMA: Direct-memory access
DTL: Diode-transistor
logic
IUE: International Ultraviolet Explorer
MMS: Multimission Modular Spacecraft
MSI: Medium-scale integrated (chips)
NSSC-t: NASA's first Standard Spacecraft Computer
OAO-C: Orbiting Astronomical Observatory C
OBP: On-board
processor
OSS-I: First Office of Space
Science
RTCP: Relative time command processor
SCP: Stored command processor
SDVF: Software Development and Validation Facility
SEX: System exerctser
SMM: Solar Maximum Mission
ST: Space Telescope
STS-3: Third Shuttle Flight
TTL: Transistor-transistor logic
TABLE I. Generalized On-Board Computer Interfaces
Input/Output Functions Description/Use
Input
from
command
receiver
Input
from
telemetry
equipment
Output to
command
distribution
equipment
Output
to
telemetry
multiplexer
Output to
transmitter
Program code, tables, and delayed
command loads
All engineering and science data for
some missions
Commands for execution
by
observatory subsystems and
instruments
Computer-generated messages to
be transmitted with observatory
format
Memory
content as a dedicated
telemetry format that allows readout
of memory independent of
program
integrity
tude control and, if desired, serve to control the teleme-
try format.
COMPUTER HARDWARE DESIGN
The computer hardware design was based on rather
general requirements, although they were derived with
the expectation that OAO-C would be the first flight
mission. The task was to develop a machine suitable for
use as a centralized spacecraft computer with only the
interfacing hardware requiring change from mission to
mission.
To meet the objective of multimission capability, the
OBP was required to
possess a comprehensive instruction set;
be reprogrammable in orbit;
be composed of low-power, radiation-resistant
circuits;
be capable of memory expansion without paying a
power penalty;
have buffered input and output channels and a
priority interrupt structure;
be capable of interconnecting redundant compo-
nents as a mission option.
Early in the development phase, Westinghouse Elec-
tric Corporation was contracted to assist an in-house
GSFC engineering group with definition and design of
the system. As the design progressed to the breadboard
stage and the decision was made to fly the computer on
OAO, Westinghouse was assigned the job of developing
the central processor unit (CPU). The input/output
(I/O) unit, which in this case had to be tailored to fit
into an existing spacecraft, was designed and imple-
mented by GSFC engineers who were familiar with the
OAO design and had direct contact with Project system
engineers and their contractor, Grumman Aerospace
Engineering Corporation. Two important ground rules
were that interconnecting the computer would not re-
quire modification of existing spacecraft boxes and that
the OBP could in no way degrade the reliability or
September 1984 Volume 27 Number 9 Communications of the ACM
903