UKube-1 is the UK’s first CubeSat mission and the pilot for a national CubeSat programme. Despite measuring a mere 10cm x 10cm x 30cm this sophisticated nanosatellite packs in 6 payloads encompassing science instruments, technology demonstration, outreach and amateur radio. A sophisticated spacecraft like UKube needs some equally sophisticated On Board Software (OBSW) running the show. We were excited to be invited by mission prime Clyde Space Ltd to develop this on their behalf. The software we developed for UKube-1 has been spun out into our industry-leading Generation 1 onboard software product.
Our Approach to the Challenge
While the development of any CubeSat mission is challenging, UKube-1 presented some particular challenges from the outset of our involvement. Chief among these were an extremely tight schedule, a number of subsystems and payloads that were still in development, and the need to deliver early capability to support hardware testing. Software development in such a dynamic environment using the aerospace industry’s traditional waterfall-based processed would be unworkable. Instead we proposed a more iterative, agile development process. This involves putting functional software in the hands of the customer at the earliest opportunity then providing incremental capability development with each iteration. At each step we are able to plan the next iteration in response to customer feedback and the evolving priorities of the wider development and testing schedule for the spacecraft.
Central to our approach is a strong partnership with the customer. We remained in regular communication with Clyde Space, both in formal meetings and day-to-day interactions with engineers over phone, email and instant messaging. We value transparency and provided full access to our code repository and online issue tracking system. While we did most of our work remotely, sometimes it really helps to physically be in the cleanroom with the hardware and the engineers who built it. So, we have always been happy to put our engineers on-site when needed. For example, we worked on-site with Clyde Space for a two-week period at the outset of the project to help kick things off effectively. During the Thermal Vacuum test campaign we were also able to provide support at Astriums’ facility in Stevenage.
Working Remotely and without Hardware
It is commonplace to subcontract software development for large traditional satellites. This usually involves the development of expensive simulators in lieu of access to real hardware. In the CubeSat world, development tends to be in-house with easy access to engineering models or flight hardware. This put us in a rather unusual position for UKube-1: developing software without a functional simulator or physical access to hardware. We were able to work with Clyde Space to set up a remote access facility which allowed us to program and operate the Onboard Computer from over 400 miles away.
Even so, access to hardware was highly-contested, so to reduce our reliance on it, we designed our software around an abstraction layer which allows the majority of development and testing to be done on standard Linux PCs. An important additional benefit of this approach is that it allows us to leverage mature automatic testing frameworks to extensively unit-test new components prior to deploying them on the OBC. To this we added the capability to simulate the space link, effectively allowing our engineers to send telecommands and receive telemetry over the internet rather than an RF link. This has proved extremely important, not only in allowing development of the OBSW to continue before ground station facilities became available, but also as the primary means of interacting with the spacecraft during hardware testing.
Highly Capable Onboard Software
Although UKube-1 might be small, the demands placed on the OBSW are not. To support a multiple payload mission with very limited ground contact time and bandwidth the OBSW must be capable of operating most of the time without ground contact. This meant that we needed to include software features more often associated with larger spacecraft such as highly capable automation, onboard scripting and file-based storage of platform and payload data.
Given the experimental nature of the UKube-1 spacecraft, we felt it was important to provide maximum flexibility to the spacecraft operators to facilitate characterisation of the platform, and to allow troubleshooting and workarounds in the event that a fault should develop onboard. We have provided a highly-configurable health monitoring system which gathers, processes, stores and downlinks telemetry from spacecraft subsystems. We have also designed the software in such a way that the low-level functionality of the software can be accessed and re-configured from the ground.
The UKube-1 Legacy
An important goal for the project was to allow reuse on future UKube spacecraft and other CubeSats. To this end we developed a flexible, highly-configurable, component-based architecture. This helps us to deliver new capabilities incrementally and greatly increases code reusability. New spacecraft will be easily supported in the future by re-deploying the components already developed and supplementing them with new components where necessary. For more information, you can check the page dedicated to the software we spun out from our UKube-1 OBSW work: Generation 1.
Image courtesy of Clyde Space Ltd.