Flight Software Design and Implementation for a CubeSat

CubeSats are on the rise and will dominate space soon due to their modularity, standardization, and lower cost. Re-using CubeSats for new missions is often possible by simply interchanging the payload ‘cubes’ with new ones that meet the new mission requirements, ideally with minimum changes to the hardware design. The problem that often arises with this level of modularity is that the Flight Software governing the operation of the spacecraft must also be modular and reusable for other missions. To achieve a degree of modularity and reduce the time required for software development, we propose a Flight Software designed from the ground up to achieve this goal. We do this by employing the following features. App-Based Flight Software: The Flight Software presented in this work comprises many Applications (Apps). The goal is to have a modular and service-oriented architecture where Apps can be added/removed based on mission requirements. Command Line Interface: Satellites typically comprise an onboard computer and many subsystems communicating via various protocols. Each subsystem has its own set of commands and responses. A human-readable Command Line Interface (CLI) is added as an abstraction layer that assists the team on the ground in controlling the spacecraft without needing to deal with the plethora of native binary commands and responses used in each subsystem. These commands can then be executed when the Satellite is on the ground using a Command Console, or they can be sent to the Satellite while in-mission using CubeSat Space Protocol packets (CLI/CSP). Script Engine: After defining the CLI command set, the same commands can be used in a Script Engine. Script files are simply sequences of commands. When a script file is triggered, commands are released and executed by the Script Engine while orbiting, whether the Satellite is still in contact or not.