CCSDS Concept Paper -- Future Spacecraft Systems Designs for Neptune and Uranus Missions

CCSDS Concept Paper

Future Spacecraft Systems Designs Optimized
for
Neptune and Uranus
- or -
Interstellar Missions of Generational Duration

Abstract
Much has been learned from the Pioneer Program, Voyager Program, Galileo and Cassini-Huygens spacecraft on what spacecraft designs are most optimal for deep space scientific research.

Suggested subsystem minimal requirements

Gyroscopic Stabilization

Voyager

Cassini
Cassini is a three-axis-stabilized spacecraft and not a spin stabilized craft. There is a set of four Reaction Wheel Assemblies (RWAs). Only three RWAs are needed for spacecraft control, with one spare. Biasing the RWAs is important for spacecraft stabilization and it is accomplished by firing the RCS thrusters while changing the RWA rotation speeds, all while the spacecraft attitude (pointing) remains fixed. RWA biases are done quite frequently and are relatively heavy users of hydrazine, but they are absolutely necessary to keep the wheel speeds within safe ranges.

Recommendations

For such a long duration mission, it is probable that 3 axis stabilization designs will be mandatory.
It is assumed that Cassini's level of redundancy (3, +1) in the end is not adequate.
It is assumed that (3, +3) might be adequate, similar to Voyager.
A level of gyro redundancy of (3, +4) must be considered.

Electrical Power
Radioisotope Thermoelectric Generators (RTGs) are absolutely necessary as no solar power is really possible at such great distances from the Sun.

It is assumed that the Multi-Mission Radioisotope Thermoelectric Generator (MMRTG) are a type of developed for NASA space missions such as Mars Science Laboratory and may be used on the Jupiter Europa Orbiter.

The MMRTGs are produced by Boeing for NASA, but any space agency for any deep space mission could use them.
The GPHS-RTG used SiGe thermoelectric elements but these are no longer in production and the MMRTG will use PbTe/TAGS thermocouples (from Teledyne Energy Systems).
The MMRTG is designed to produce 125 W electrical power per module at the start of mission, falling to about 100 W per module after 14 years.

General power recommendations

At least 3 MMRTGs should be used on the primary craft.
At least 1 MMRTG (of lesser power and weight) should be used on any ancillary craft.
The bare minimum craft electrical power at the beginning of a mission should be 350w or if ancillary craft shares power 400w.
If RTGs become available that are capable of providing 1.0 kw at the beginning of a mission, they must be considered.

Computing

General recommendations

To conserve heat and mass, spacecraft and instrument electronics should be housed together in IEMs (Integrated Electronics Modules).
There should be redundant IEMs for each computer system.
CPU speeds should be no higher than 50 MHz to conserve power, with 250 nm processes.
CPU dormancy speed should be 2.5 MHz or 1.5 MHz, as it is expected that 2/3 rds of the total mission time will be spent in transit.

CPU systems worth consideration (Primary Computers)
The RAD750 is a radiation-hardened single board computer, based on IBM's PowerPC 750. The RAD750 is manufactured by BAE Systems. It is intended for use in high radiation environments such as experienced on board satellites and spacecraft. The RAD750 was released for purchase in 2001 and the first units were launched into space in 2005.

The CPU has 10.4 million transistors which is nearly ten times more than the RAD6000 which had 1.1 million transistors and it is manufactured using either 250nm or 150 nm photolithography and has a die area of 130 mm².
The RAD600 has a core clock of 110 to 200 MHz and can process at 266 MIPS or more.
The CPU can include an extended L2 cache to improve performance.
The CPU itself can withstand 2,000 to 10,000 grays and temperature ranges between –55 °C and 125 °C and requires 5 watts of power.
The standard RAD750 single-board system (CPU and motherboard) can withstand 1,000 grays and temperature ranges between –55 °C and 70 °C and requires 10 watts of power.
The RAD750 system has a price that is comparable to the RAD6000 which is US$200,000 per board.

CPU systems worth consideration (Secondary Computers)
The New Horizons spacecraft carries two computer systems, the Command and Data Handling system and the Guidance and Control processor. Each of the two systems is duplicated for redundancy, giving a total of four computers. The processor used is the Mongoose-V, a 12 MHz radiation-hardened version of the MIPS R3000 CPU.

The Mongoose-V 32-bit microprocessor for spacecraft onboard computer applications is a radiation-hardened and expanded 10–15 MHz version of the MIPS R3000 CPU.

The Mongoose was developed by Synova, Inc. of Melbourne, Florida, USA, with support from the NASA Goddard Space Flight Center.
The Mongoose-V processor first flew on NASA's Earth Observer 1 (EO-1) satellite launched in November 2000 where it functioned as the main flight computer. A second Mongoose-V controlled the satellite's solid-state data recorder.

Mongoose-V Features

MIPS R3000 Instruction Set
MIPS R3010 Floating-point Unit
On-Chip 2KB Data Cache
On-Chip 4KB Instruction Cache
Speed grades 10MHz, 15MHz

Software Development Boards with 32-bit Rad-Hard Mongoose-V microprocessor

Mongoose-V microprocessor fabricated using 1-MRAD Silicon-On-Insulator (Silicon on Saffire) technology
The board is immune to single event upsets
Spaceflight qualified units are readily available
Pricing for Mongoose-V Software Development Board (MV-SDB-01) is around $30,000 USD per board.

Command and Data Handling

Navigation and Systems Control

Each of the two systems is duplicated for redundancy, giving a total of four computers. The processor used is the Mongoose-V, a 15 MHz radiation-hardened version of the MIPS R3000 CPU -- that should be capable of running at 2.5 MHz during sleep or dormant phases of the mission.

Multiple clocks and timing routines should be implemented in hardware as well as software to help prevent faults or downtime.

Image Processing

Data Storage

Data Storage

Solid state recorder
A minimum of 3 low-power solid-state recorders (one primary, one backup, one interstellar backup -- not used until interstellar mission begins) holding up to 8 gigabytes (64 gigabits) each. One should assume that there is about 2% less available for data storage due to file system overhead.

Image Processing

Cameras

Notes about light levels on the 2 outer gas giants

Uranus/Earth Comparison

Solar irradiance (W/m²) U = 3.71 vs E = 1367.6 differential is 0.0027 less than Earth.

Black-body temperature (K) U= 58.2 vs E = 254.3 differential is 0.229 less than Earth.

Neptune/Earth Comparison

Solar irradiance (W/m²) N = 1.51 vs E = 1367.6 differential is 0.0011 less than Earth.

Black-body temperature (K) N = 46.6 vs E = 254.3 differential is 0.183 less than Earth.

As a general rule, visible light cameras should be able to cope with 1 w per square meter.
As a general rule, infrared cameras should be able to cope with 40 K blackbody imaging conditions.

Breakdown of cameras by megapixel capabilities and bit depths.

RULE : All cameras should be autonomous to whatever extent is possible. The older Voyager Program arrangement of having camara controls linked to the flight subsystem should no longer be needed. Each camera should have its own 2 core (or 4 core) 32 bit CPU with Error Correcting Memory and an autonomous pointing system. Each camera should also have its own command and control system that is able to obtain spacecraft state to determine when to acquire images.

Visible Light

2 x 4 mpx x 16 bits
2 x 2 mpx x 16 bits
2 x 1 mpx x (12 or 8) bits, mostly this recommendation is for navigation cameras

Visible Light Navigation Cameras

2 sun locators @ 256 kpx, 10 bit but with 8 bit fallback mode
2 star locators @ 256 kpx, 12 bit but with 8 bit fallback mode

Infrared

2 x 2 mpx x 16 bits if feasible
2 x 1 mpx x 14 bits

Ultraviolet

2 x 2 mpx x 16 bits

Craft observing cameras

2 x 1 mpx x 16 bits, monochrome if visible
The camera must have at least 4 megabytes of memory, its own operating system and compression subsystem

Telecommunicastion Subsystems

The difficulty of establishing a link between a spacecraft and a DSN station is, to a first order, a function of the required data rate and the square of the distance over which the link is occurring. Hence, a simple measure of end-to-end link difficulty can be obtained by taking the product of the data rate and the square of the distance. Note that this measure makes no assumptions about the telecommunications capabilities of either the spacecraft or the DSN ground station at each end of the link. It is simply indicative of the inherent difficulty of the link itself. Over the next 25 years, this downlink difficulty is expected to increase by roughly two-and-a-half orders-of-magnitude.

End-to-end uplink difficulty trends are, of course, similar to those of the downlink difficulty trends and involve roughly the same driver missions. However, because of the asymmetry between uplink and downlink rates for robotic missions discussed earlier, the effective isotropic radiated power needed to support the uplink to such missions is within the capability of the current DSN (assuming appropriately sized high-gain antennas onboard the spacecraft and forward-error correction coding on the uplink when needed).

However, such requirements and their associated link difficulties are generally bounded by the problem of providing emergency uplink at outer planet distances. The DSN’s current 70-meter, 20 kW, X-band capability enables spacecraft at Jupiter’s maximum distance from the Earth to receive a 7.8125 bps emergency transmission via their omni-antennas. To enable emergency uplink into an omni antenna at greater distances, the equivalent of 10 to 20 times the current 20 kW capability on a 70 m uplink dishes is needed, depending upon one’s spacecraft assumptions (e.g., system temperature, receiver loop bandwidth, etc.).

CCSDS suggested using bandwidth efficient technique compatible with Block V receiver structure in a deep space network. JPL is now researching deep space exploring mission (eg. MRO) modulation schemes suitable for future high data rate (eg.10-100Mbps) by combining high efficient error correction code (eg. Turbo and LDPC code) including

Offset QPSK (O-QPSK) : For phase restriction, its peak average power ratio (PAPR) is smaller than that of BPSK and standard QPSK. Two research keystones in O-QPSK are how to use rectangular and square root raised cosine (SRRC) pulse shaping techniques.
Pre-encoded GMSK : Pre-encoding technique is used to compensate differential coding of MSK modulator. Consequently, it can avoid power performance reduction in modulator and demodulator system resulted by combination of differential coding at sender and differential decoding at receiver.
Trellis-coded OQPSK : By using two-state convolutional encoder to introduce memory among sending data and raised cosine pulse waveform, OQPSK signal of improved envelope performance can be obtained.
FQPSK : By introducing a controllable correlation and adopting given signal waveform between in-phase and quadrature arms (its envelope is similar to constant), the FQPSK modulator can be regarded as a 16-state joint I-Q TCM modulator.
In order to further improve bandwidth efficiency, more envelope fluctuations bandwidth efficient TCM technique is now being a research hotspot.

Known problems of deep space communications

Long Distance : A lot of planets in deep space are several hundred million kilometers away from the earth. Such long distance results in very low signal to noise ratio (SNR).
High Signal Propagation Delays : This is due to the enormous distances involved between the communicating entities and the relativistic constraint restricting signal transmissions to the speed of light. For example, one-way signal propagation delays for the Cassini mission to Saturn are in the range of 1 hour and 8 minutes to 1 hour and 24 minutes.
High Data Corruption Rates : Extremely long distances cause the signals to be received at extremely low strengths at the receiver, and thereby increase the probability of bit-errors in the channel due to random thermal noise errors, burst errors due to solar flares, etc.
Disruption Events : Since communicating entities in deep-space tend to be in motion relative to one another, the communication channel between them is prone to disruption. A planetary probe on the surface of Saturn’s moon Titan, for example, could experience disruption due to the rotation of Titan on its own axis (when it goes to the night side of Titan), when Titan passes under Saturn’s shadow during its revolution around the planet, and when other moons / planets/or the Sun itself block the line of sight to the destination.

General goals

Primary communication with the spacecraft should be via X band (7.1–8.4 GHz),.
Secondary communications and radio science experiments should be possible via Ka band (32–34 GHz), with data rates similar to X band.
Primary telemetry communication should be via S band.
Due to the vast distances involved, error correction systems must be chosen that offer the most reliable coding.

Targets

The backup engineering telemetry communication system should use the S band, but it should be possible to allocate up to 50% of the data stream to science data.
There should be a target X band downlink rate of 40 kbit/s at Jupiter.
There should be a target X band downlink rate of 20 kbit/s at Uranus.
There should be a target X band downlink rate of 10 kbit/s at Neptune.
The spacecraft should have a minimum 100% redundancy of transmitters and receivers.
The spacecraft should use Right-Hand Circular Polarization and Left-Hand Circular Polarization (RHCP & LHCP).
The downlink signal is amplified by dual redundant 15-watt TWTAs (traveling-wave tube amplifiers) mounted on the body under the dish.
The primary X band system should permit control to power both TWTAs at the same time. This option should permit a dual-polarized downlink signal, with a 90% increase in the downlink datarate.

Downlink prioritization
A "Data Priority Paradigm" with 3 tunable parameters of control for applications, namely Immediacy, Probability of Delivery and Mission Value.

Ideally the system should be based on using Immediacy and "Probability of Delivery" but "Mission Value" should act like a 'gamma correction' factor to tweak up the delivery of some data streams or image files.

Immediacy : Immediacy is a notion of how urgently a unit of application data (called a "job" in the subsequent discussion) needs to be received. For example, a message from a science instrument entering a critical state implying status such as \Instrument too hot", \Low battery condition" or commands such as "Stop! Don't go down that" sent from Earth, might need to be reported ahead of all other experimental results / commands. We say that such a job has higher immediacy requirements over the others.
Probability of Delivery (PoD) : In the space environment where there is always a non-trivial bit-error rate on the channel, the communication channel cannot guarantee 100% reliable data delivery. Some application jobs may seek higher PoD guarantees compared to others however. For example, the picture of a microbe found on the surface of Titan may be of much more importance to the mission compared to regular house-keeping telemetry data, and thus may need higher probability of delivery requirements.
Mission Value : How valuable is the data to the mission. "Mission Value" should act like a 'gamma correction' factor to tweak up the delivery of some data streams or image files.

How this might work

Jobs in Cloud A [high immediacy (low actual value), low PoD] could include spacecraft location data and certain classes of telemetry data which must be delivered within a very small timespan or the data would not be valid or valuable any more for the receiver. This includes classes of telemetry data updates that are sent often enough that the loss of a single update is not critical.
Jobs in Cloud B [high immediacy (low actual value), high PoD] could carry data representing critical instrument status seeking immediate attention (Instrument too hot" or "Battery draining too fast") or urgent commands sent on the uplink that need to be operated on ahead of all other ongoing jobs ("Stop by that interesting rock for a while"-command being sent to a rover on Mars).
Jobs in Cloud C [low immediacy (high actual value), high PoD] could include important results of scientific experiments, various interesting images that need to be sent reliably, but not necessarily urgently.
Jobs in Cloud D [low immediacy (high actual value), low PoD] could include relatively less important scientific data and bulk data that may be sent just on a best-efforts basis. Note that while there typically is a large solid-state data store available on spacecrafts, its capacity is finite, and an implementation
of our priority paradigm would store jobs in Cloud C ahead of jobs in Cloud D, and under severe storage space constraints may even choose not to store Cloud D jobs for transmission.

Here, we consider various mechanisms that could be used to guarantee the priority requirements of application jobs.

Adapting the error correction mechanisms We might choose to increase the quality of Forward Error Correction (FEC) mechanisms in use for the higher priority jobs and thereby improving the chances of transmitting them successfully, with the additional overhead this would impose.
Modulating the number of redundant transmissions In a scenario as is typical in current deep-space missions, the FEC mechanisms and frame sizes tend to be used for a mission phase. In such a case, the only option we may have to guarantee the job priority requirements might be to transmit the frames redundantly in original transmission. We believe that such a simple mechanism is being used in current missions when the command / data to be sent is extremely critical.
Adapting the frame size. We might choose to decrease the size of datalink frames for the higher priority application tasks, improving the chances of successful transmission of each frame. This would introduce additional overhead in data transmission as the header data to application data ratio would increase.

Error Correction

Lessons from the Voyager Program and Galileo craft

Galileo
The Galileo spacecraft was only able to transmit mission data through a low-gain antenna because the high-gain antenna on board the spacecraft has refused to deploy properly and was essentially useless. This failure scenario should be avoided at all costs by using fixed, solid antennas -- but this failure scenario risk cannot be eliminated.

The data rate from this antenna was not designed to exceed 100 bits per second. To offset some of the perform ante loss, the spacecraft’s computer had to be extensively reprogrammed to include new data compression and coding algorithms.

The baseline coding system for the low gain antenna mission uses a Reed-Solomon code of block length 255 concatenated with a (14, 1/4) convolutional inner code, and interleaves the Reed-Solomon symbols to depth 8. The convolousionally encoded symbols are decoded by a maximum likelihood (Viterbi) decoder. Each Reed-Solomon decoded codeword is then decoded algebraically.

In order to fix the problem of only being able to use the low gain antenna 2 types of decoding enhancements were proposed. These coding enhancements involve “re-decoding” of some of the data.

The first type of re-decoding is confined to the Reed-Solomon decoder and utilizes information from neighboring codewords within the same interleaved block to erase unreliable symbols in un-decoded words. The second type involves re-decoding by the Viterbi decoder, using information fed back from codewords that have been successfully de-clocked by the Reed-Solomon decoder.

Several conclusions were drawn from the analysis and delivered to the (Galileo mission planners. These comparisons are valid for the Galileo system using a (14, 1/4) convolutional coded depth-8 interleaving of Reed-Solomon symbols, and achieving a final decoded bit error rate of 1 x 10–7. A second stage of Viterbi decoding without any Reed-Solomon erasure declarations is worth about 0.37 dB relative to the baseline system.

Adding two more stages of Viterbi decoding is worth an additional 0.19 dB for a total gain of 0.56 dB. The marginal additional improvement from utilizing erasure declarations was shown to be around 0.19 dB for one-stage decoding (no Viterbi re-decoding), but only 0.02 dB for two-stage decoding and essentially nil (0.00 dB) for four-stage decoding.

General recommendations

Primary Communication System (downlink baudrate > 300 bps)

The Galileo high gain antennae failure forced the low gain antenna into becoming the primary antenna for the mission -- this failure scenario should be avoided at all costs by using a similar 3m fixed dish antenna capable of 10000 bps at Neptune's radius.
Antenna polarization : LCHP (Left Hand Circular Polarization) and RCHP (Right Hand Circular Polarization) should be implemented, as this provides better noise filtering vs the typically Horizontal and Vertical polarizations found from natural sources.
Three transmitters

Engineering Telemetry System (downlink baudrate < 300 bps)

There is a possibility of failure of the primary antenna, so the Engineering Telemetry System must be ready to serve as a backup primary transmission subsystem.
The Engineering Telemetry System need to have some backup capability for the primary antenna system, that is to say it must be capable of 300 bps at Neptune's radius if the primary antenna system fails
Normal Engineering Telemetry System downlink rates should be 100 bps, but 50 bps should be available for fallback.

Uplink Command System

Uplink Software Update System

Ancillary craft

Created by
Max Power

Original ideas
15 April 2007

Document Created
11 November 2009

Last modified
13 August 2010

CCSDS Concept Papers : http://public.ccsds.org/publications/ConceptPapers.aspx

CCSDS Concept Papers are working documents of the Consultative Committee for Space Data Systems (CCSDS), its Areas, and its Working Groups.

Note that other groups may also distribute working documents as CCSDS Concept Papers.

CCSDS Concept Papers have no official status and are simply the vehicle by which technical suggestions are made visible to the CCSDS. They are not part of any archival document series and these documents should not be cited or quoted in any formal document.

Unrevised documents placed in the CCSDS Concept Papers directories have a maximum life of nine months. If a document progresses to a CCSDS Proposed Standard, it will be replaced in the CCSDS Concept Papers Directories with an announcement to that effect.