The general need and requirements for the onboard embedded processors necessary to control and manipulate data in spacecraft systems are discussed. The current known requirements are reviewed from a user perspective, based on current practices in the spacecraft development process. The current capabilities of available processor technologies are then discussed, and these are projected to the generation of spacecraft computers currently under identified, funded development. An appraisal is provided for the current national developmental effort

Benz, Harry F.

English

NASA Technical Reports Server

N90-27152
ONBOARD PROCESSOR TECHNOLOGY REVIEW
Harry F. Benz
NASA Langley Research Center
Hampton VA
Abstract
In this short review paper, I discuss the general need and requirements for the
onboard embedded processors necessary to control and manipulate data in spacecraft
systems. I review the current known requirements from a user perspective, based on
current practices in the spacecraft development process. I then discuss the current
capabilities of available processor technologies, and project these to the generation
of spacecraft computers currently under identified, funded development. I provide an
appraisal of the current national developmental effort.
Introduction
By nature of an introduction, I will recite a number of assumptions that are
embedded in the NASA practices of implementing missions. I will then bring some
practical realities of implementing new embeddable computer resources into these
missions.
A good reference for backup material for this paper is the "NASA Space Systems
Technology Model" Volume liB, Chapter ii. More current material is included in the
GAO Report "Space Operations, NASA Efforts to Develop and Deploy Advanced Spacecraft
Computers."
For NASA to "sell" a mission project, the program manager must assure NASA
senior management that the technology to implement the mission is "in hand." The
Office of Aeronautics and Space Technology in its "NASA Space Systems Technology
Model" has embedded a seven-layer description of technology readiness for
implementation. For those readers with experience with the military description of
the process of technology development, these generally correspond to the levels of
6.1, 6.2, etc. Readiness level seven implies that the technology has been used
successfully in the relevant environment, and it is essentially "off the shelf." The
goal of every NASA program manager is to use this "off the shelf" technology in his
mission to simultaneously minimize risk, minimize cost, and meet mission goals. To
gain performance or short-term cost advantage, a mission project manager may use a
technology that is a little less mature and incur a little risk. This use of
technology at the level six, or engineering model tested implies that the technology
is mature but has not been used successfully in the relevant environment. A typical
flight program takes five years from inception or proposal to flight. A year is
taken for mission definition and technology tradeoff studies, three years for
subsystem or payload development and test, and a final year for system integration
and flight vehicle integration and test.
Most researchers andtechnology developers within NASA, especially those
supported by the Office of Aeronautics and Space Technology, perform basic research
at level one, where the basic physical phenomenon is discovered; or at applied
research at levels two through four, or five, where the physical phenomenon is
engineered into a conceptual design, the conceptual design is tested, the critical
functions are tested, and major components are tested. With increasing levels of
complexity, there is an exponential increase in associated developmental cost, and an
123
https://ntrs.nasa.gov/search.jsp?R=19900017836 2020-03-19T21:15:11+00:00Z
increasing level of committment required by the OAST program management from the
project user program office to keep the expensive technology development from
"withering on the vine." In the processor development area, there has never been
sufficient resources made available from the OAST program to carry computer
development to level seven. The computers that NASA uses have been primarily adapted
from military or militarized commercial computers. An example of such a computer is
the NASA Standard Spacecraft Computer that was repackaged for the space environment
by the NASA Standard Parts Program, run by the NASA Chief Engineer's Office. The
most recent example is the Gallileo computer, the Harris 80C86, which is a redesigned
gate level copy of the Intel 8086 with a radiation hard fabrication and a limited
amount of single-event upset immunity.
Within the commercial semiconductor industry, there is a rule of thumb that the
capability of a technology will double every three years. In order to maintain a
product market in this rapidly expanding technology area, the semiconductor
manufacturers must have an overlapping developmental program. The time necessary to
develop each next generation manufacturing capability is two or three years. The
time necessary to design the next generation component technology is three years.
The time to win market share for a new processor is a year, and the useful
manufacturing lifetime is about three years.
To build a processor in the current environment, there is a fifty-million-dollar
engineering investment to design, to manufacture, to integrate hardware, and to
develop software operating systems and higher level language compilers. This cost
must be recoverable from sales and does not include the component production
facility. The facility costs are roughly one hundred million to capitalize and forty
million per year to operate. Every three to five years, with increasing complexity,
this facility must be recapitalized.
This has brought about an apparent paradox. To propose and build in mission
hardware, the hardware must be mature in the marketplace. With a five-year mission
development cycle, by the time the hardware is launchable, it is no longer available
in the marketplace. It has become obsolete. Thus, we are building systems of
obsolete hardware. The components must be delivered from warehouses of obsolete
parts. Since they are no longer manufactured, it is impossible to acquire more
should the warehouse become depleted without significant capital and manufacturing
costs, which are beyond the scope of the mission. Both the DoD and NASA have
recognized this for years, but there appears to be no long-term solution. This is a
characteristic of a growth technology.
The military and space semiconductor manufacturers are almost wholly captive to
the military and space industries and thus the government. The system operating
environments and requirements are significantly different; there is somewhat of a
carryover of manufacturing methods and practices; and there is a higher cost at
almost an exclusively government-subsidized marketplace. The government recognizes
this and is attempting to help through sponsorship of the Very High Speed Integrated
Circuit (VHSIC) program, the MMIC program, the GaAs pilot line facility, and most
recently with Semitech. The industry recognizes this and has been attempting to
remedy it through Microelectronics and Computing Corporation (MCC) and Semiconductor
Researc_ - (SRC).Corporation
Thus there are fundamental differences in the requirements, cost, marketplace,
schedules, and readiness that confound the use of current or next-generation
commercial processing technology in the space mission environment.
124
Requirements of the Natural Space Environment on Processors
The space environment imposes a number of physical constraints on the hardware
to be used in spacecraft payloads. The physical constraints which must be met are
the vacuum of space which imposes the constraint that all the electronics must be
conduction cooled to maintain junction temperatures and thus long time reliability.
This is normally done at the subsystem level into a heat rejection system. This
conduction cooling forces a mass penalty onto the launch vehicle. The more power
there is to dissipate, the more massive the thermal distribution and dissipation.
Power is also much more expensive to generate. This has traditionally forced
acceptance of low power complementary logic families to reduce the static dissipation
of power.
In the Complementary Metal Oxide Semiconductor (CMOS) logic, standby power is
near zero, and all power is dissipated dynamically by changes of logic state. This
implies that the processor hardware can be powered down by reducing the system clock,
a simple concept that allows operational phase tradeoff between tasks to be processed
and the available power. Thus the speed power product is of critical importance to
optimize functionality. The spacecraft orbit for the particular spacecraft also is
important. Low earth equatorial orbits are relatively inexpensive to reach, and the
natural radiation is reduced by the earth's shadow and magnetosphere. High
geostationary orbit is expensive because of the energy required to launch and the
higher radiation environment. Polar orbit is more expensive to launch because the
launch vehicle cannot take advantage of the earth°s motion, and the radiation
environment is much more severe because of the lack of shielding by the magnetosphere
at the poles, and the low polar altitude of the Van Allen belts, which are
encountered twice each orbital period for the life of the mission.
The natural radiation environment is not so severe as the military strategic
weapons environment, but several constraints are similar. The hardware must be
designed at the cell within the chip level to be total dose tolerant to the level of
the expected mission orbital life. It must be latch-up free. With the development
of logic at the 1.25 micrometer minimum feature size, the amount of charge that
retains the logic level within the cells of the devices is less than that deposited
by a cosmic ray passing through the cells of the device. Parasitic devices
inadvertantly designed into the devices by following best commercial packing rules
allow virtual Silicon Controlled Rectifier devices to exist within the wells of a
CMOS device. There is no gate to allow these devices to turn on, and there is no
means to turn them off. These cosmic rays in traversing the whole spacecraft pass
through these devices on a statistical basis and turn on the SCR devices. This
causes catastrophic device failure. The cosmic rays also can upset the logic by
simply overwriting memory cells in conventional memory or within registers in a
CPU. The logic must be designed to be "bullet proof." This additional design
constraint costs design specialization, design time, and chip area. This is in
direct opposition to the marketplace drivers of the commercial chip developer.
The commercial chip developer is interested in maximizing the number of gates on
a chip whose parameters are centered within the commercial, market-driven
manufacturing production facility. With the incorporation of 1.25-micrometer
technology into digital flight control systems on military and commercial aircraft
which fly at higher altitudes, cosmic ray latch-up and upset will likely become
significant drivers in the cost and system complexity of such systems. Conventional
passenger aircraft normally fly significantly above the protection that the
atmosphere provides for cosmic rays. In a normal transcontinental flight, the
125
typical radiation dose to a passenger is equivalent to a chest x-ray, primarily
caused by other charged particles, but with a cosmic ray component. When these
systems are finally flown, there will likely be many unexplained upsets identified in
the fault tolerant architectures. Whether these fault tolerant control systems can
recover their system integrity and state between single event upsets is yet to be
determined. Thus in the current integrated circuit technology epoch, there should be
a merging of aeronautics and space requirements in the cosmic ray area.
The remoteness of the environment imposes additional constraints. The hardware
must be testable on orbit to aii6w operational validation. Except for Shuttle-
reachable satellites, the hardware cannot be repaired during its operational life;
therefore, it must include a level of fault tolerance and must have carefully
predicted failure statistical models.
Mission cost is a primary driver. Individual NASA space missions simply cannot
afford to develop their own hardware as one-time deveI0pmentso Another primary
driver is performance. No mission can accept performance that is unable to meet its
needs. The commercial sector has made great progress in its marketplace. The
adaptation of commercially manufactured products for the space environment is very
costly and involves significant redesign. Only few commercial vendors see this
government-only space marketplace as a place for long-term profitability.
Desirable Attributes of a Spaceborne Processor
The attached requirements and targets should be achievable by the mid 90's for
technology levels six and seven from a variety of sources. The Generic VHSIC
Spaceborne Computer, developed by IBM and Honeywell through the SDIO/AFSTC SAT 144
program for use in their BSTS currently offers the most short term promise over the
80C86 used in Gallileo. On the technology horizon, the Rad Hard -32 bit processor,
under development by a variety of consortia through the SDIO/AFRADC SAT 143 program
SSTS, offers the next most promising processor epoch. The short term targets and
goals are centered on a GVSC multiprocessor specification.
Current Spaceborne Processor Capabilities
i have Collected from various sources, including commercial product offerings,
spacecraft mission documents and developmental planning documents, a representative
collection 0f the currently available processors. I have included this collection in
Table I as:_ProCessor Characteristics. By best e_stimates, I have attempted to
categorize its suitability and readiness, i will discuss the characteristics that I
have identified as columns in the table. I have categorized these columns as:
performance, using standard instruction set mixes where available (including the
DAIS, and Whetstone which, primarily, have suitability for control-type algorithms
with some arithmetic)_ the power 0fthe_PU_chipset; the radiation hardness and
mechanisms; the self-testability; sponsors; and other remarks. In Table 2, I have
followed the same format, and have identified when the implementing CPU chipset was
or is planned to be ready for use in the radiation hard space environment, when the
memory management unit is ready, when a bus interface unit is ready, and when a gate
array for use in "glue logic" is ready. I must note here that a chipset and a
fabri6ati0n technology do not make a spacecraft computer. Also in columns are the
CPU-ALU width for performance, the size of the memory space directly addressable, and
the high level software tools available for the user programmer. An additional
survey was pubifshed in the June, 1989, issue of "Defense Science," in an article
126
entitled, "Radiation Hardness--The New Requirement" by J. S. Tirado and the
accompanying chart entitled "4th Annual Directory of Radiation Tolerant IC's."
Conclusions
The technology is sufficiently mature to build an experimental ISES. If EOS
NPOP-I holds schedule, the SDIO/AFSTC-sponsored Generic VHSIC Spaceborne Computer
hardware will be ready and "off the shelf." If the EOS NPOP-I schedule slips, the
SDIO/AFRADC-sponsored Radiation Hard 32-bit processor, a RISC-MIPS-based chipset,
will then be sufficiently mature for ffoff the shelf 'ruse.
127
DESCRIPTION OF REQUIREMENTS FOR EMBEDDED PROCEDURES
0 PERFORMANCE - INSTRUCTION RATE FOR STD MIX, DAIS, WHETSTONE, DHRYSTONE, ETC.
0 POWER - CMOS TO SMALLEST FEATURE SIZE - PRIMARY IMPACT ON WEIGHT
0 WEIGHT - LEO, EQUATORIAL IS EXPENSIVE; POLAR IS VERY EXPENSIVE, GEO EVEN MORE
0 SIZE - TO MEET MOUNTING/THERMAL INTERFACE
0 ENVIRONMENT
o TEMPERATURE - MIL STD TEMPERATURE RANGES
o VACUUM - OUTGASSING, HEAT FLOW
o VIB - LAUNCH
o EMI/RFI INTERNAL/EXTERNAL - CANNOT INTERFERE WITH SENSORS, CANNOT BE
INTERFERED WITH IN PRESENCE OF HIGH POWER XMTRS, SAR
o RAD HARD CMOS - SINGLE EVENT LATCH UP FROM COSMIC RAYS
TOTAL DOSE - BENIGN ENVIRONMENT WITH POTENTIAL BELT CHARGING
SINGLE EVENT UPSET FROM COSMIC RAYS
0 TESTABILITY - VALIDATION ON ORBIT
0 FAULT TOLERANCE - FAIL OPERATIONAL, FAIL SAFE, CANNOT CONTRIBUTE TO MISSION
FAILURE
0 MTBF/MTBCF - CONSISTENT WITH MISSION LIFE
0 "SECURITY"/INTEGRITY - PROTECTION FROM INTRUDERS, ACCIDENTS
ISES REQUIREMENTS (R)/TARGETS (T)
0 PERFOR_NCEI 25 HIPS AGGREGATE DAIS MULTIPROCESSOR (T)
0 PoWER_ 200 W (T)
0 WEIGH?: 40 KG (T)
0 SIZE: 1/2 ATR, 6" X i0 " x 20" (T)
0 ENVIRONMENT:
o TEMPERATURE - MIL SPEC -55°C TO +125°C OPERATING (INTERNAL)(R)
o VACUUM - HERMETIC DURING STORAGE/ALL CONDUCTION COOLING (R)
o VIB - LAUNCH ENVIRONMENT (R)
o EMI/RFI - NON INTERFERING WITH MISSION/SCIENCE SENSORS (R)
o RAD HARD CMOS - NO SINGLE EVENT LATCH UP (R)
--TOTAL DOSE: 3E5 RADS_2S;(R FOR POLAR, GEO)
SINGLE EVENT UPSET, LET > 42, IE-IO UPSETS/BIT-DAY (T)(R FOR CONTROL)
o TESTABILITY - 100% (T)
0 FAULT TOLERANCE - FAIL OPERATIONAL, FAIL SAFE, REDUNDANCY
..... TECHNIQUES ONLY (R)
0 _@_ 160K HR/3OOK HR (T)
0 "SECURi?Y"/INTEGRIT¥ TO MEET MISSION REQUIREMENTS (R)
(KEY R = REQUIREMENT)
T = TARGET
128
TABLE I. PROCESSOR CHARACTERISTICS
PROCESSORS
(CHIPSET ONLY) PERFORMANCE
1802 i00 KIPS
BOC86 ?
SA3300 750 KIPS
469R 2 3 HIPS
RI-RCA 1750 500 KIPS
GVSC (2) 4 HIPS
B0386 4 MIPS
MDC281 630 KIPS
RH-32 (4-2) 25 HIPS
GAAS HIPS (2) 200 HIPS
RAD
HARD
0.5 W YES
BULKCMOS 2M
BULK CHOS
0.5 W YES - LIMITED
AND LATCH UP
1.5 W YES
BULKCMOS
CMOS-SOS
3 W YES
2 W YES
CMOS-SOS
5 W YES
BULK-CMOS
3 W NO (?)
BULK-CMOS
3 W NO ?
BULK-CMOS
3 W YES
BULK-CMOS
15W (CPU) YES
GAAS
NO
NO
_ARKS
MAGELLAN
MATURE (COMHONLY
USED)
_GALrLEO
MANY PECULIAR SEU
UPSET SPEC
DOE CRAF
CANDIDATE
NO
NO CDC-IRAD/SDIOMOSTVERSATILE
NO MIDGETMAN PROPRIETARY
ICBM
VHSIC-AFSTC/SDIO-BSTS
SDIO
100%
NO NASA-SSF
NASASS INTERES
IN REVERSEENGINEERING
FOR RAD HARD
NO MDAC-1RAD COFS
DARPA-ORD- MIPSR-5000
100% SDIO JIAWGCAP32
- SDIO- SSTS
NO DARPA-ORD CURRENTLY
25 NIPS
TABLE 2. PROCESSOR CHARACTERISTICS (CONCLUDED)
MMU
PROCESSORS READY
1802 - (RCA) 75 N/R N/R 1980 8
H80C86 (HARRIS) 1985 NO YES 1985 16
SA3300 (32032)/(SANDIA) 1988 90 90 1988 32
469R2 (CDC/1750) 1987 N/R N/R 1987 16
RI-RCA 1750 1988 N/R N/R 1985 16
GVSC (2) (1750A)/ 1989 1989 1989 1988 16
(IBM-HONEY)
80386 YES YES YES 1989 32
HDC 281 MDAC/MARCONI 87/89 NO PLANS (SCI) 88 (H-)B7 16
_H-32 (4-2) (CORE MIPS) 90 91 91 90 32
JNISYS/UTMC-IBM-
TRW/MDAC-HONEY/_EST
GAAs HIPS (2)
TI-HDAC
90
MEMORY
SPACE
HIGH LEVEL
SOFTWARE
584K x 86 1802 ASS'Y
BASIC, FDRTRAN
? PASCAL, -C "
252 x 168 ADA
64K x 168 JOVIAL/1750
64K x 168 JOVIAL/1750
64K x 16B/ ADA/1750
258K x 168
232 x 168 ADA-C-PASCAL
FORTRAN
64K x 16
256K x 16 TARTAN ADA
2x232x328 RISC-ADA/TLD
ADA/CSALI-COREMIPS
2X232X328 ADA/CORE MIPS
129
CONCLUSIONS
THE CURRENT STATE OF THE ART FOR SPACECRAFT ON-BOARD COMPUTING IS LIMITED.
EXPERIMENTS EMBODIED AS PROGRAMS MUST BE RELATIVEL¥ UNSOPHISTICATED.
130


Onboard processor technology review

Abstract

Similar works

Full text

Available Versions

NASA Technical Reports Server