08. Command and Data Handling

Introduction

There are two primary trends in small spacecraft command and data handling (C&DH). The desire to incorporate small spacecraft, especially in the cubesat class, into more complex science and technology applications in LEO and deep space or interplanetary missions requires increased system reliability and performance. In the case of the smaller spacecraft, these objectives are complicated by the use of highly integrated systems and the need for power and mass efficiency.

At the other end of the spectrum, low-cost easy-to-develop systems that take advantage of open source software and hardware are providing an easy entry into space systems development, especially for those who lack specific spacecraft expertise or for the hobbyist.

State of the Art

Since the publication of the first edition of this report, several cubesats using commercial-off-the-shelf (COTS) components and integrated systems have successfully flown in the LEO environment, over short mission durations of typically less than one year.

A variety of C&DH development for cubesats has spanned in-house development to new companies that specialize in cubesat avionics and established companies who provide spacecraft avionics for the space industry in general. Presently there are a number of commercial vendors who offer highly integrated systems that contain the on-board computer, memory, electrical power system (EPS) and the ability to support a variety of input & output (I/O) for the cubesat class of small spacecraft.

In anticipation of the extended duration in LEO and deep space missions, vendors are incorporating radiation hardened or radiation tolerant designs in their cubesat avionics packages.

Form Factor

The CompactPCI and PC/104 form factors continue to be the industry standard electronics bus systems with multiple vendors offering components that will integrate into systems that can be space rated.

The PC/104 board dimension continues to be the baseline for cubesat configurations. Many vendors have adopted the use of stackable “daughter” or “mezzanine” boards in order to simplify connection between subsystem elements and payloads, as well as to accommodate advances in technologies while maintaining compatibility with existing designs. A few vendors provide a modular package, which allows users to select from a variety of computational processors.

On-Board Computing

Microcontrollers and FPGAs

Small spacecraft, and especially cubesat developers, continue to use microcontrollers and field programmable gate arrays (FPGAs) supporting a variety of different processor cores. FPGAs have successful legacy in space and continue to lend themselves to high levels of integration providing peripherals, on-chip memories and improved power performance, factors that influence the choice of on board computing at present. See Table 8.1 for current state of the art highly integrated on-board computing systems for small spacecraft use.

Table 8.1: Sample of Highly Integrated On-board Computing Systems
Product Manufacturer Processor Status
Nanomind A712D GomSpace ARM7 TRL 9
ISIS OBC ISIS ARM9 TRL 9
Pluggable Socketed Processor Module Pumpkin C8051F120, PIC24F256110, PIC 24F256GB210, MSP430F1612, MSP430F1611, MSP4302618 TRL 9
MODAS Utah State University TI320C6713DSP TRL 9
Proton X Box Space Micro P200K (TI DSP); P400K (Freescale PowerPC Dual Core); P300K (FPGA Virtex 5 or 7) TRL 9
Proton 2X Box Space Micro P300K(TI DSP); P300K FPGA (Virtex 5 or 7); P400K (Freescale P2020 dual core PowerPC processor) TRL 9
Intrepid Tyvak ATMEL AT91SAM9G20 TRL 9
Q7 Xiphos Xilinx Zynq 7020 ARM dual core Cortex A9, Actel ProASIC3 Control FPGA TRl 9
Q6 Xiphos Xilinx Spartan-6, Actel ProASIC3 Control FPGA TRL 9
Q5 Xiphos PowerPC 405 TRL 9
ArduSat NanoSatisfi ATMEL ATmega328P TRL 9

Many power efficient microcontrollers used in cubesats feature ARM processors and a variety of on-chip peripherals, especially communications such as universal serial bus (USB), controller area network (CAN), as well as I2C interfaces and serial peripheral interface (SPI). There has also been an increase in the number of microcontrollers that integrate flash memory, as most of their advantages are centered on programmability.

System developers are gravitating towards ready-to-use hardware and software development platforms that can provide seamless migration to higher performance architectures. As with non-space applications, there is a reluctance to change controller architectures due to the cost of retraining and code migration. Following the lead of microcontrollers and FPGA vendors, cubesat avionics providers are working towards providing simplified tool sets and cost effective basic evaluation boards.

Smartphone Based Processing

Further demonstrating COTS hardware, NASA’s PhoneSat~1.0 and SSTL’s STRAND-1 flew cubesats that used Google Nexus One smartphones as the central processor. Smartphones exploit a large market with a fast design cycle, and incorporate several key features that are used in spacecraft, such as cameras, radio links, accelerometers and high performance computer processors. The smartphone cores used on those early spacecraft were based upon the Qualcomm Snapdragon system on chip (SoC) with a 1 GHz Scorpion processor running the Android operating system. Phonesat~1.0 simply flew the phone in a cubesat chassis along with a battery pack for power and a UHF beacon radio.

The hobbyist market that has subsequently emerged from smartphone app development experienced the same I/O bottlenecks and mounting problems observed by these smartphone spacecraft. Consequently, a range of low-power microprocessors are now available, although still based on ARM and often running Android, but providing better modularity. No smartphone based cubesat avionics kits are available commercially at this time.

Open source platforms

A number of open source hardware platforms hold promise for small spacecraft systems. Arduino boards consist of a microcontroller with complementary hardware circuits, called shields. The Arduino platform uses Atmel microcontrollers, therefore developers can exploit Atmel’s development environment to write software. The ArduSat spacecraft used the Arduino platform and successfully engaged the public to raise funding on Kickstarter. BeagleBone has also emerged as a popular open source hardware platform. BeagleBone contains an ARM processor and supports OpenCV, a powerful open source machine vision software tool that could be used for imaging applications. BeagleSat is an open source cubesat platform based on the BeagleBone embedded development board. It provides a framework and tool set for designing a cubesat from the ground up, while expanding the cubesat community and bringing space to a broader audience. Raspberry Pi is another high-performance open source hardware platform capable of handling imaging, and potentially, high-speed communication applications [1].

Finally, Intel has entered the market with their Edison system. The dual-core x86-64 SoC was targeted at “Internet of Things” applications but the Edison has proven very well suited for advanced cubesat development, a novel use that Intel has embraced.

Arduino has become known for being beginner friendly, and making the world of microcontrollers more approachable for software designers. Though it presents a set of relatively familiar API to developers, it does not run its own operating system. On the other hand the BeagleBone Black, Raspberry Pi and Intel Edison are full-featured embedded Linux systems, running Angstrom, Raspbian and Yocto Linux kernels out of the box respectively. This broadens the range of developer tool options, ranging from web based interfaces to Android and Python environments. Not only does this further ease the learning curve for novice developers, but it allows the full power of a Linux system to be harnessed in computation tasks.

Memory and Electronic Components

The range of on-board memory for small spacecraft is wide, typically starting around 32 kB and increasing with available technology. For C&DH functions, on board memory requires high reliability. A variety of different memory technologies have been developed for specific traits, including static random access memory (SRAM), dynamic RAM (DRAM), flash memory (a type of electrically erasable programmable read-only memory), magnetoresistive RAM (MRAM), ferro-electric RAM (FERAM), chalcogenide RAM (CRAM) and phase change memory (PCM). SRAM is typically used due to price and availability. A chart comparing the various memory types and their performance is shown in Table 8.2.

Table 8.2. Comparison of Memory Types
Feature SRAM DRAM Flash MRAM FERAM CRAM/PCM
Non-volatile No No Yes Yes Yes Yes
Operating Voltage, ±10% 3.3 – 5 V 3.3 V 3.3 & 5 V 3.3 V 3.3 V 3.3 V
Organization (bits/die) 512k x 8 16M x 8 16M x 8; 32M x 8 128k x 8 16k x 8
Data Retention (@ 70°C) N/A N/A 10 years 10 years 10 years 10 years
Endurance (Erase/Write cycles) Unlimited Unlimited 106 1013 1013 1013
Access Time 10 ns 25 ns 50 ns after page ready; 200 ?s write; 2 ms erase 300 ns 300 ns 100 ns
Radiation (TID) 1 Mrad 50 krad 30 krad 1 Mrad 1 Mrad 1 Mrad
SEU rate (relative) Low-nil High Nil (cells); Low-med (device electronics) Nil Nil Nil
Temperature Range Mil-std Industrial Commercial Mil-std Mil-std Mil-std
Power 500 mW 300 mW 30 mW 900 mW 270 mW
Package 4 MB 128 MB 128 – 256 MB 1 MB 1.5 MB (12 chip package)

There are many manufacturers that provide a variety of electronic components that are considered high reliability and space rated and can be seen in Table 8.3. A visit to any of their respective websites will show their range of components and subsystems including processors, FPGAs, SRAM, MRAM, bus interfaces, application specific integrated circuits (ASICs), and low voltage differential signaling (LVDS).

Table 8.3: Sample of Highly Integrated On-Board Computing System Manufacturers
ATMEL Honeywell STMicroelectronics
BAE Systems Intel Texas Instruments
Broadreach Intersil 3D Plus
C-MAC Microtechnology Maxwell Technologies Xilinx
Cobham (Aeroflex) Microsemi (Actel) Arduino
Freescale Space Micro, Inc. BeagleBone

Bus Electrical Interfaces and I/O

Cubesat class spacecraft continue to utilize those interfaces that are commonly used in the microcontroller or embedded systems world. Highly integrated systems, especially SoC, FPGA and ASICs, will typically provide several interfaces to accommodate a wide range of users and to ease the task of interfacing with peripheral devices and other controllers. Some of the most common interfaces are listed below with a brief description:

  • Serial Communication Interfaces (SCI): RS-232, RS-422, RS-485 etc.
  • Synchronous Serial Communication Interface: I2C, SPI, SSC and ESSI (Enhanced Synchronous Serial Interface).
  • Universal Serial Bus (USB).
  • Multi Media Cards (SD Cards, Compact Flash etc.).
  • Networks: Ethernet, LonWorks, etc.
  • Fieldbuses: CAN-Bus, LIN-Bus, PROFIBUS, etc.
  • Timers: PLL(s), Capture/Compare and Time Processing Units.
  • Discrete IO: General Purpose Input/Output (GPIO).
  • Analog to Digital/Digital to Analog (ADC/DAC).
  • Debugging: JTAG, ISP, ICSP, BDM Port, BITP, and DB9 ports.
  • SpaceWire: a standard for high-speed serial links and networks.

     Electronic Power Supplies

A number of developers still design their EPS in-house. This is usually the case when the payload has power control needs and requirements that cannot be met by the commercially available suppliers. As the EPS is a critical system for the spacecraft, developers will typically utilize high reliability or space rated components.

There are several commercially available EPS for the cubesat platform. These systems provide voltages and regulation typically utilized in embedded systems such as 3.3 V and 5 V.

These systems also provide an array of features to address end user needs, such as short circuit protection, over current and over/under voltage protection, telemetry, battery charging and monitoring, reset capability and more depending upon the vendor. Many of these systems have flight heritage and are therefore greater than TRL 6. Table 8.4 provides a short list of vendors who provide EPS solutions for the cubesat platform.

On the Horizon

Many C&DH systems will continue to follow the trends set for embedded systems. Short duration missions in LEO will continue to take advantage of the advances made by industry leaders who provide embedded systems technologies and components. In keeping with the low cost rapid development theme of the cubesat-based missions, many COTS solutions are available for spacecraft developers.

Radiation mitigation solutions are being implemented by developers who need to address those concerns as applied to deep space and long duration LEO missions. A brief discussion about those techniques is provided in Radtion subsection below.

Also trending in the cubesat development arena is the use of open source solutions. A number of C&DH systems being developed are utilizing Linux as their OS. This is allowing them to take advantage of open source SW that has been developed and tested [1]. NASA has developed open source software to support a number of missions. Others developers are using the open source in its truest sense, providing software libraries and on-line tools to aid in the development of their space systems. A brief discussion on open source is provided in [2].

Radiation mitigation and tolerance schemes

Deep space and long duration LEO missions will require developers to incorporate radiation mitigation into their respective designs. The cubesat platform has traditionally utilized readily available COTS components. Use of COTS parts has allowed for low cost C&DH development while also allowing the developers to take advantages of state of the art technologies in their designs. Many of the component and system vendors also provide radiation hardened (rad-hard) equivalent devices as well. While there are many commercially available rad-hard components, use of these components has an impact to the overall costs of spacecraft development. In order to keep costs as reasonable as possible, C&DH developers will need to address appropriate use of rad-hard components along with other radiation mitigation techniques for development of an overall radiation tolerant design as discussed in the following section.

Radiation mitigation and tolerance schemes

For space applications, radiation can damage electronics in two ways. Total ionizing dose (TID) is the amount of cumulative radiation received. Single event effects (SEE) is the disturbance created by single particles hitting the electronics [3]. Total dose is measured in krad and can affect transistor performance. Single event upsets (SEU) can affect the logic state of memory. A single event latchup (SEL) can affect the output transistors on CMOS logic, potentially causing a high-current state. The purpose of this section is to summarize techniques used to mitigate system failures caused by radiation effects.

Component Selection

MEMORY

FRAM (Ferroelectric RAM) is a non-volatile random access memory that is persistent like Flash memory. FRAM memory cells are latched using a PZT film structure which is more likely to maintain state during a single event effect than traditional capacitive latches found in RAM  [4], [5].

IMAGING

Charge couple devices (CCD) and complementary metal oxide semiconductors (CMOS) are image sensors that are useful in radiation environments. However, CCD’s are preferred in space applications while the CMOS detectors is a newer technology for rad hardened image sensors [6], [7][8]–[10].

Protection Circuits

WATCHDOG TIMERS

Watchdog timers are often used to monitor the state of a processor. A watchdog timer is a hardware circuit, external or internal to the processor, that resets the processor when it expires unless refreshed by the processor. If the processor jumps to an erroneous memory location through a single-event upset or a software exception, the watchdog timer resets the processor to restore operations [11].

COMMUNICATION WATCHDOG TIMER

A dedicated communication watchdog timer circuit can monitor command and responses to determine if the system is locked up. Such a circuit resets power after a specific number of failed transmissions.

OVERCURRENT PROTECTION

Single event latchup (SEL) can cause device failure due to an elevated current state. Hardware and software overcurrent protection can be implemented to watch for elevated current levels and then issue a power reset to the offending circuit. The sampling frequency for software overcurrent protection must be sufficient to detect and reset the subsystem before the elevated current causes permanent damage. For hardware protection, a shunt resistor and bypass diode can be used to in conjunction to filter voltage and current spikes for rad hardened devices.

POWER CONTROL

Since many components are more prone to radiation effects when powered on, a candidate mitigation strategy is to power off devices when they are not needed operationally.

Memory Protection

ECC MEMORY

Error-correcting code memory is capable of detecting and correcting bit errors in RAM and FLASH memory. In general, ECC works by storing a checksum for a portion of the memory. This checksum can be used to simply mark a portion of memory unusable and/or correct single-bit errors. The memory controller is responsible for managing the ECC memory during read and write operations [12].

SOFTWARE EDAC

Bit errors can be detected and corrected using software. In general, EDAC algorithms use three copies of the memory to detect and correct bit discrepancies. Software routinely “scrubs” the memory, compares each of the three stored memory value, selects the majority value, and corrects the erroneous memory location. Software EDAC can be performed at the bit or byte level. Memory lifetime needs to be considered for software EDAC implementations since every correction increases the write count to a memory location.

Communication Protection

SHARED BUS MONITORING (I2C)

I2C is a standard communication protocol for sharing device peripherals. I2C consists of a clock and data line. Individual peripherals on the bus use these common lines to communicate with a master controller. In the event that an individual device locks up communication, the master controller can monitor and reset the device to restore communication for all devices.

SHARED BUS SWITCHING

Another option is to decouple the clock and data lines so that each peripheral has it’s own pair. Additional data lines can be used on the master controller. Alternatively, an external FPGA could be used to assign a unique clock/data pair to each peripheral and, optionally, include a method a way to reconfigure those assignments in flight.

CRC

Cyclic redundancy check (CRC) is a common method for detecting memory or communication errors. Parity is a single-bit implementation of a CRC where the bit of summary information is calculated by the XOR of the data to be communicated or stored to memory. For communication channels, a CRC is calculated prior to sending the message and is appended to the message stream in a known location. When the message is received the CRC is calculated again and compared to the previously generated CRC appended to the data stream. For memory, the CRC is calculated prior to writing the data to memory. When the data is read out, a new CRC is calculated and compared to the previously generated CRC. CRC’s help detect data corruption but cannot be used to correct the defective data.

FORWARD ERROR CORRECTION

FEC transmits redundant data to help the receiver recover corrupted data. In it’s simplest form, FEC could transmit three bits for every bit of data and then vote to restore the original data. More efficient algorithms balance the data overhead with the correction accuracy [11].

Parallel Processing and Voting

TRIPLE MODULAR REDUNDANCY

Single-event upsets can interrupt discrete logic, including processing. Triple modular redundancy (TMR) is a fault mitigation technique where logic is replicated three times and the output of the logic is determined by a majority-vote.

FIRMWARE PROTECTION

Many spacecraft subsystems include a processor to handle and optimize operations. These processors require firmware which is written into onboard program memory. Like data memory, program memory is also susceptible to single-event upsets and device failure. To counter this issue, a bootloader may be used to check the validity of the firmware and provide a mechanism for uploading new versions. Additionally, multiple copies of the firmware may be stored in memory in the case that the primary version is corrupt.

Open Source Spacecraft Software

Open Source software offers spacecraft developers a way to accelerate software development, improve quality, and leverage lessons learned from prior missions.

CFE/CFS

The Core Flight Executive (cFE) is an application development and runtime environment developed by Goddard Space Flight Center. cFE includes core services like messaging, timekeeping, events, and table-driven commanding and configuration [2], [6].

COSMOS

COSMOS is a tool developed by Ball Aerospace that provides a framework for operating and testing an embedded system. The tool includes modules for telemetry display, plotting, scripting, logging, and configuration table management [4].

Linux

Linux is currently supported by several spacecraft avionics providers including Space Micro and Tyvak. Additional software modules are needed for space applications. Such modules may include memory scrubbing, a safe mode controller, watchdog functionality, and other reliability services [7].

Conclusion

System level solutions are in demand and a majority of the small spacecraft bus developers utilize hardware typically employed in the embedded systems and control world. As a result there are many sources for cubesat systems, subsystems and components from vendors who provide complete spacecraft bus avionics solutions, which include on-board computing, memory, electronic power supply and engineering development systems. As cubesat development and application continues to evolve, there are a wide range of avionics systems and components available to address the needs of the wide range of small spacecraft developers, professional and amateur.

Designing and fabricating avionics systems for harsh radiation environments is mitigated by a combination of shielding, derating and controlling operating conditions for cumulative ionization and displacement damage effects that cause gradual degradation in electronic devices. Small spacecraft, especially in the cubesat class, will need to address impacts of radiation in deep space missions and extended duration missions in LEO. Several processor manufacturers and board level integrators are addressing the need for radiation hardened and radiation tolerant designs. Some board level integrators have also undertaken radiation testing of their integrated systems. Many integrated systems providers, are utilizing radiation hardened processors or FPGAs from manufacturers such as XILINX, ATMEL, Aeroflex.

Open source software and hardware hold a lot of promise for commercial and government spacecraft developers. Making a project open source is the first step. The next step is to socialize the software and encourage developers to not only use but to contribute back flight-proven algorithms, software modules, and hardware components.

Cubesats are playing a large role in rapidly developed low cost missions in space, as they are establishing technology demonstrations and short duration science missions in LEO. NASA and other space agencies are now exploring their application in deep space missions. The cubesat community will provide innovative solutions to address the reliability requirements necessary for those missions, while attempting to maintain the low cost approach associated with the platform. Complete avionics packages are available to those who seek an integrated solution. At the other extreme, open source DIY kits are available to those who seek a low cost way to explore developing their own C&DH system and spacecraft.

For Feedback solicitation, please email: arc-sst-soa@mail.nasa.gov. Please include a business email so someone may contact you further.

[1]
P. Wooster, D. Boswell, P. Stakem, and J. Cowan-Sharp, “Open Source Software for Small Satellites,” in Proceedings of the AIAA/USU Conference on Small Satellites, 2007, no. #SSC07-XII-3.
[2]
S. Fitzsimmons, “Open-source Software for CubeSat Satellites,” in Proceedings of the AIAA/USU Conference on Small Satellites, 2012.
[3]
M. Nguyen, “FPGA Advances Improve Radiation Mitigation for Remote-Sensing Satellites,” vol. 17, no. 8, 2015.
[4]
Ball Aerospace & Technologies Corp, “The User Interface for Command and Control of Embedded Systems.” 2015.
[5]
H. Henkel, “Total Dose Radiation Tests at FRAM Non-Volatile Memories.” 1996.
[6]
NASA Goddard Space Flight Center, “Core Flight Software System.” 2015.
[7]
NASA Goddard Space Flight Center, “GSFC Open Source Software.” 2015.
[8]
A. Bardoux, A. Penquer, O. Gilard, R. Ecoffet, and M. Auvergne, “Radiation effects on image sensors,” in International Conference on Space Optics, 2012, no. ICSO-2012-5-163.
[9]
T. Chapman, “Radiation Tolerances.” 2015.
[10]
K. E. Holbert, “Single Effect Events.” 2015.
[11]
R. Mauere, M. Fraeman, M. Martin, and D. Roth, “Harsh Environments: Space Radiation Environment, Effects, and Migitation,” vol. 28, no. 1, 2008.
[12]
K. A. LaBel et al., “Commercial Microelectronics Technologies for Applications in the Satellite radiation Environment,” in Aerospace Applications Conference, 1996, vol. 1.