Space missions of all kinds have been lost because of software errors, including those engineered by experienced teams from the largest space agencies in the world; well-funded interplanetary probes such as ESA’s Schiaparelli and NASA’s Mars Climate Orbiter are but two examples.
Much smaller teams with intentions of launching a CubeSat will have to deal with the same degree of space environment challenges, plus many additional risks originating from allowing an amateur user to run code on a satellite’s onboard computer. Therefore, it is important to describe what risks we are going to face, and the preventive measures we are going to take to optimise the odds of mission success. They can be roughly grouped into mission risks and business risks. Firstly, we will talk about mission-specific risks and their mitigation.
Mission Risks
Running code written by people without extensive prior experience in space software development is the largest challenge we face in developing a mission of this kind, in addition to the usual risks that come with CubeSat development.
…and Possible Countermeasures
The core concept of our solution is the implementation of multiple layers of software and hardware guards as well as operational procedures, forming a defence-in-depth strategy to reduce the risk of premature mission termination.
- First and foremost, the design of our satellite in general, on-board data handling, and the commands subsystem will follow current practices in nanosatellite design and construction. We plan to utilize flight-proven parts from existing nanosatellite vendors to reduce any unforeseen risks and leverage the reliability of flight heritage solutions.
- Secondly, our onboard data-handling and command system will be split into primary and secondary partitions, where the primary partition will act as a supervisor with priority in commanding the satellite subsystems and can override user code execution on the secondary partition. The mission software and operating system on the primary will be selected or designed by our team and will not be accessible or overwritable by our satellite users.
- Thirdly, a degree of flight envelope protection will be implemented for the mission software – runtime environment on host operating systems will provide safety checks and threshold limits for potentially dangerous user command sequences.
As the primary operational precaution, before any user code will run in space, it has to pass the comprehensive test procedures on the ground, from basic sanity checks to predictive analysis of the satellite behaviour using “digital twin”, synced with the real satellite using real-time telemetry. In the case of mission-critical emergencies the secondary on-board computer running misbehaving user code will be powered-off, either through command from the ground station or by autonomous decision-making of the primary on-board computer.
Technical solutions are not the only actions we should be using. There is no substitute for experience, and the moment we will be able to secure sufficient funding to start our mission design, we will be hiring people with experience in nanosatellite mission design and operation: system engineers, electrical and mechanical engineers, software developers and orbital mechanics experts. A lot of necessary answers will be obtained during our collaboration with ESA’s OPS-SAT mission, to be launched in just a few days, on December 17, 2019, so we will not be operating in the blind when the time comes for our own mission in late 2020.
In our next update we will describe the potential business risks and our approach to minimise them.