Article Preview
TopIntroduction
This paper documents the design and implementation of a complete flight software system for a CubeSat (Heidt et al., 2000) housing a 16-bit Microchip dsPIC-33F microcontroller with a mere 32 kB of on-chip static RAM. This CubeSat, CSUNSat1, is the product of a four-year collaboration between CSUN and the Jet Propulsion Laboratory (JPL), and was developed by a team of over 70 students (Benson et al., 2016; Bolotin et al., 2015; Chin et al., 2014-15; Kaplan, Flynn and Katz, 2014). This CubeSat’s mission is to carry out one or more research experiments while in low earth orbit. These experiments may be specified and prepared on the ground as a scripted sequence of steps while the CubeSat is already in flight, and later uploaded from ground to the CubeSat via communication link. Experimental results collected by the CubeSat (hereafter referred to as telemetry readings) may likewise be downloaded from the CubeSat to the ground.
CSUNSat1 (shown in Figure 1) must function under extraordinary design constraints, including the aforementioned RAM capacity. Moreover, equipment budget and physical space limitations prevent us from employing radiation-hardened memory, forcing us to consider the effects of space radiation on our system state and data integrity. Finally, the satellite must be able to sample 44 independent hardware sensors every second and record this data for later transmission to ground on-demand. Such a performance demand is met by a fully custom-written flight software OS, designed specifically for this mission with the goal of providing maximum availability in the presence of space effects.
CSUNSat1 has no attitude control, and is therefore tumbling in space. Additionally, CSUNSat1 will be launched into low earth orbit (LEO). Thus, communication between satellite and ground is opportunistic and limited to small windows of time, forcing CSUNSat1 to perform independent self-maintenance and reliably store multiple weeks of experimental data.
The CSUNSat1 flight software is designed to maximize predictable satellite behavior in an adversarial space environment. This software is not programmed using a conventional off-the-shelf embedded real-time operating system (RTOS) such as VxWorks (Wind River Systems, 2016), Salvo (Kalman, 2004), FreeRTOS (Barry, 2010), or RODOS (Barschke, Großekatthöfer and Montenegro, 2014). Rather, we have designed and implemented the operating system (OS) ourselves, specified as a deterministic state machine (Schneider, 1990).
Important system state is maintained in a global data structure. This global structure is stored in triple-modular redundant (TMR) fashion for fault tolerance, allowing the satellite to tolerate a large degree of memory corruption and/or failure. Periodic checks on the integrity of attached storage, as well as an extensive Anomaly Resolution Subsystem, further enable us to tolerate and even actively mitigate potential faults resulting from space radiation.
Figure 1. The Fully Assembled CSUNSat1
TopA CubeSat (Heidt et al., 2000) is a miniature satellite (20 x 10 x 10 cm) capable of carrying an onboard experiment into space. The NASA CubeSat Launch Initiative (CSLI) (National Aeronautics and Space Administration, 2016) provides a launch free of charge for some educational and/or non-profit CubeSats. These CubeSats are “piggybacked” on government and commercial satellite launches around the world and have a potential lifetime of 25 years, orbiting the earth approximately every ninety minutes. For this reason, CubeSats and nanosatellites in general are drawing interest as a low-cost platform for space experimentation, particularly in educational environments (Straub et al., 2013; Tsuda et al., 2001).