Onboard Software Development 400 Miles From the Cleanroom: Component-based Reusable Software for UKube-1
Session
Pre-Conference: CubeSat Developers' Workshop
Abstract
While the development of any CubeSat is challenging, UKube-1 presented some particular challenges from the outset of our involvement as Onboard Software subcontractors. Chief among these were a tight schedule, subsystems and payloads that were still in development and the need to deliver early capability to support hardware testing. Despite the late stage at which we joined the project, the operational concept for the mission was not clear and many requirements were uncertain or ill-defined. One thing we did know for sure was that many requirements would not be tied down until very late in the development. This paper describes our experiences and lessons learned from the development of software for UKube. In this dynamic environment a traditional waterfall-based process would be unworkable, instead we employed a more iterative, agile approach. This involved putting functional software in the hands of the customer at the earliest opportunity then providing incremental capability with each iteration. At each step we were 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. We also attempted to build flexibility into the design of the software itself. The architecture is based around many individual components, each of which is relatively simple. These execute on an abstraction layer, decoupling them from the underlying operating system. We were thus able to develop components on standard Linux PCs and leverage mature automatic testing frameworks to carry out extensive unit-testing prior to deploying them on the OBC. The overall function of the software comes largely from the ways in which these components are used (the deployment). Reconfiguring a deployment gave us an easy way to accommodate late changes to operational requirements without having to modify component code. When hardware subsystems changed, the uniform component framework meant that code changes were limited to the subsystem component and could be unit tested. When software development is subcontracted for large spacecraft, a simulator is usually used in place of hardware. In most CubeSat projects this expense is not necessary as the software is developed in house with good hardware access. For UKube we had neither physical access to the hardware nor a simulator. Instead, we were able to set up a remote access facility which allowed us to program and operate the OBC from over 400 miles away. The I/O abstraction framework in the software allowed us to substitute a simulated spacelink, allowing us to send telecommands and receive telemetry over the internet rather than an RF link. This proved important, both for OBSW development before ground station facilities became available, and as the primary means of interacting with the spacecraft during hardware testing. Although UKube-1 might be small, the demands placed on the OBSW are not. The spacecraft has multiple payloads and yet the mission must operate with limited ground contact and bandwidth. We therefore needed to include software features more often associated with larger spacecraft such as highly-capable automation, onboard scripting and file-based storage. A configurable health monitoring system gathers, processes, stores and downlinks telemetry from spacecraft subsystems. All system features can be accessed and re-configured from the ground. This provides maximum flexibility to the spacecraft operators to facilitate platform characterisation and troubleshooting, crucial for an experimental spacecraft such as UKube. An important goal for the project was to allow reuse on future UKube spacecraft and other CubeSats. The component-based architecture also 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.
Presentation Slides
Onboard Software Development 400 Miles From the Cleanroom: Component-based Reusable Software for UKube-1
While the development of any CubeSat is challenging, UKube-1 presented some particular challenges from the outset of our involvement as Onboard Software subcontractors. Chief among these were a tight schedule, subsystems and payloads that were still in development and the need to deliver early capability to support hardware testing. Despite the late stage at which we joined the project, the operational concept for the mission was not clear and many requirements were uncertain or ill-defined. One thing we did know for sure was that many requirements would not be tied down until very late in the development. This paper describes our experiences and lessons learned from the development of software for UKube. In this dynamic environment a traditional waterfall-based process would be unworkable, instead we employed a more iterative, agile approach. This involved putting functional software in the hands of the customer at the earliest opportunity then providing incremental capability with each iteration. At each step we were 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. We also attempted to build flexibility into the design of the software itself. The architecture is based around many individual components, each of which is relatively simple. These execute on an abstraction layer, decoupling them from the underlying operating system. We were thus able to develop components on standard Linux PCs and leverage mature automatic testing frameworks to carry out extensive unit-testing prior to deploying them on the OBC. The overall function of the software comes largely from the ways in which these components are used (the deployment). Reconfiguring a deployment gave us an easy way to accommodate late changes to operational requirements without having to modify component code. When hardware subsystems changed, the uniform component framework meant that code changes were limited to the subsystem component and could be unit tested. When software development is subcontracted for large spacecraft, a simulator is usually used in place of hardware. In most CubeSat projects this expense is not necessary as the software is developed in house with good hardware access. For UKube we had neither physical access to the hardware nor a simulator. Instead, we were able to set up a remote access facility which allowed us to program and operate the OBC from over 400 miles away. The I/O abstraction framework in the software allowed us to substitute a simulated spacelink, allowing us to send telecommands and receive telemetry over the internet rather than an RF link. This proved important, both for OBSW development before ground station facilities became available, and as the primary means of interacting with the spacecraft during hardware testing. Although UKube-1 might be small, the demands placed on the OBSW are not. The spacecraft has multiple payloads and yet the mission must operate with limited ground contact and bandwidth. We therefore needed to include software features more often associated with larger spacecraft such as highly-capable automation, onboard scripting and file-based storage. A configurable health monitoring system gathers, processes, stores and downlinks telemetry from spacecraft subsystems. All system features can be accessed and re-configured from the ground. This provides maximum flexibility to the spacecraft operators to facilitate platform characterisation and troubleshooting, crucial for an experimental spacecraft such as UKube. An important goal for the project was to allow reuse on future UKube spacecraft and other CubeSats. The component-based architecture also 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.
