DESIGN DECISIONS FROM THE HISTORY OF THE EUVE SCIENCE PAYLOAD
                              W. Marchant
              Center for EUV Astrophysics, 2150 Kittredge St., 
         University of California, Berkeley, California 94720, USA


ABSTRACT

   NASA's Explorer class instruments are intended as low-cost, quick-turn-around
missions.  Associated with those admirable goals, however, is the necessity of
accepting a higher risk of design or implementation flaws in the flight hardware
and software systems.  This paper will discuss some of the design issues that
arose during the development of the EUVE science payload at UC Berkeley, how
they were solved, and how those decisions have worked out, based on the suc-
cessful completion of the survey phase of the EUVE science mission.


1. OVERALL ARCHITECTURE: SMART SPACECRAFT VERSUS SMART PAYLOAD

   The EUVE mission was proposed in 1975, just after the first successful de-
tection of an extreme ultraviolet object by a Berkeley instrument flown on the
Apollo-Soyuz mission [1].  Design of the EUVE instrument proceeded slowly at
UCB, until the formal start of contract in 1984.  Since the mission was not
formalized, the spacecraft design was unknown.  The project had surveyed a num-
ber of spacecraft-to-payload interfaces and had developed a baseline interface
that could be used until a spacecraft was chosen.  The lack of a firm space-
craft design forced the EUVE payload to handle virtually all functions intern-
ally.  The payload expected only a reference clock, a single 16-bit serial
command input, 28 Volts of power, and control of pyrotechnic devices for un-
covering the telescope bores.  The payload returns a 16 kilobit/second serial
telemetry stream synchronous with the reference clock.
   The final design for the payload electronics centered around a single 8-bit
microprocessor computer (telescope interface unit, or TIF) for each of the de-
tectors and one computer (the command, data, and power, or CDP, computer) to
act as a buffer between the TIFs and whatever spacecraft bus was eventually
chosen.  The CDP would also be responsible for controlling power distribution
and heater control on the science payload.
   With the selection of a Fairchild Aerospace Multimission Modular Spacecraft
(later to be known as the Explorer platform, or EP), in 1985, the payload in-
terfaces had to be modified.  The EP interface boxes (RIU, or remote interface
unit) are extremely capable [2].  The generic nature of the science payload 
baseline interface used a fraction of the RIU capabilities and required only
the addition of a small "daughter board" to the CDP.
   Given the capabilities of a RIU during the initial design phases, the CDP
would probably become redundant.  Obviously this would save money during early
development.  However, with the uncertainty of spacecraft vendor, the stand-
alone payload design allowed UC Berkeley to proceed in its development efforts
while NASA contracted for a spacecraft.  The autonomy of the spacecraft and
payload also seems to have yielded benefits during integration:  the extremely
limited interface provided little opportunity for problems.


2. PARALLEL OR SERIAL BUSSES?

   With a multiple computer architecture, such as that of the EUVE science
payload, one must decide how to interconnect the computers.  Ground-based
systems will often use a serial local area network.  There are a number of
single-chip implementations of such communications links, and some spacecraft
are starting to use this architecture.  Another option is to use a parallel bus
structure.  The EP spacecraft uses this approach.  Serial busses are desirable
because they limit the number of electrical connections in cables and on elec-
tronics boards.  Some of that advantage may be offset by reduced speed and the
possibility of requiring complicated software or interface circuits.
   The EUVE payload uses a combination of busses.  Parallel busses are used
internally for microprocessor-to-memory access.  Serial busses, mostly driven by
software, are used elsewhere.  This has resulted in a great savings in cable
wire counts between the computers.  The disadvantage was an increase in the
role of the software in driving those interfaces.


3. RAM OR ROM FOR SOFTWARE?

   For main software storage and execution, RAM (readable and writeable memory)
seems to be a popular choice among spacecraft designers.  A complete RAM im-
plementation allows the maximum flexibility in case of design changes or pro-
blems.  It also allows the possibility of writing complete software systems for
a specific portion of a mission.  The corollary is that it can become difficult
to constrain further changes to the software systems.
   Systems based on ROM (read-only memory) naturally need to contain the soft-
ware for all portions of the mission.  Knowing which version of software is
installed is much easier, and definite time deadlines can be assigned for the
completion of software.  Drawbacks include the danger of catastrophic problems
in the software, and the possible difficulties of including software updates
after hardware is integrated.
   The EUVE electronics use a combination of these approaches.  The software is
resident in ROM but at several critical points the software transitions, for a
few instructions, to RAM.  This allows the possibility of replacing sections of
the software system by changing the portion that exists in RAM.  The project
was confident enough to use the ROM approach because of an aggressive use of
modern programming practices.  The software went through four planned major
revisions, with extensive testing and reviews at the end of each.  The flight
electronics and software were also scheduled so that they could be used for
calibrating the flight optical systems.  This allowed us to accumulate hundreds
of hours of experience with the flight software before committing to ROM, as
well as provided invaluable feedback on our ground systems design and a chance
for the payload controllers to interact with the science payload and the sci-
entists.  The project also maintains the electronics breadboards as a test and
training facility.
   Not surprisingly, several minor bugs and deficiencies were discovered even
during integration with the spacecraft and after launch.  RAM resident patches
for these were easily implemented.


4. HOW MUCH (IF ANY) MEMORY ERROR DETECTION AND CORRECTION IS ENOUGH? 

   Memory checks are often used in computers with massive quantities of RAM me-
mory.  Spacecraft usually have smaller quantities of memory but a much harsher
environment (especially from radiation) than most ground computer systems.  The
environment, combined with the possibly disastrous consequences, explains why
memory errors are a serious concern to spacecraft system designers.
   Some forms of RAM, notably magnetic core memories, are very resistant to
radiation induced errors.  Because core memory is typically bulky (compared
to semiconductor), it is eliminated as an option in some applications.  Some
semiconductor memories are also resistant to the effects of radiation.
   Another option is to have hardware (and occasionally software) that will
attempt to detect and correct memory errors.  This option typically involves
extra hardware that may make a system more vulnerable to failure.
   The EUVE project decided to rely upon radiation-resistant memory because of
the satellite's low orbit of 550 km.  The semiconductor memory chosen for the
main RAM storage has a history of being very resistant to single event upsets
(SEUs) and latchups.  Single event upsets occur when a charged particle passes
through a semiconductor memory device and deposits enough electrical charge to
flip the device from one state to another.  Latchups involve the permanent state
change of the bit.  Sometimes latchups can be "fixed" by powering the device
off then on again.  The EUVE project has seen five SEU "incidents" during the
first eleven months of operation.  This compares very favorably to our pre-
launch estimates of one incident per month of operations.


5. COMPLEX OR SIMPLE COMMAND STRUCTURES? 

   A typical commanding interface will use 16-bit commands transmitted serially
from the spacecraft to a payload.  The EP spacecraft has dozens of this type of
interface "port" available for each payload.
   The EUVE payload, as discussed earlier, uses a single 16-bit interface port.
One possible approach involved using one byte as an op-code (seven bits of data
and a parity bit) and the other byte as a data value for the op-code.  This
works well if the command lines are clean and do not produce spurious commands.
Another option was to use the simple commands to build up a more complex com-
mand structure, one that could include more error detection mechanisms.
   Because the project did not know how sophisticated the spacecraft would be,
it was decided to use the "built-up command" mechanism.  Sixteen-bit commands
(with an odd parity bit) are built up into a "macro" consisting of an identi-
fier, command count, body of commands (each with its own parity bit), and a
final block check character.  This commanding scheme added substantially to the
complexity of the EUVE payload commanding interface but made spurious command
execution very unlikely.  One of the dangers of a mechanism such as this is
that an excessively noisy command channel could preclude any commands from be-
ing completed.
   Fortunately, this has not been the case with the EP.  The project has seen
two bad parity commands during ground testing and none by the payload while on
orbit.


6. SUMMARY

   The early design decisions made for EUVE paid off in a scientific payload
that was delivered to NASA on time and on budget.  Science payload to space-
craft integration testing went very smoothly and the EUVE science payload and
spacecraft have enjoyed an outstanding survey phase.


REFERENCES
 
1. S. Bowyer, "EUV Astronomy on the Apollo-Soyuz Mission: The First Detection
	of Stellar EUV Sources and Other Astrophysical Results", in Extreme
	Ultraviolet Astronomy, Pergamon Press, New York, pp. 3-7 (1991).
2. P.R.K. Chetty, Satellite Technology and its Applications, McGraw-Hill, 1991,
	p. 261.