Design Guidelines for General-Purpose Payload-Oriented Nanosatellite Software Architectures

Abstract

Despite their limited lifespan and reduced cost, nano-satellite missions have proved to be suitable platforms for Earth observation, scientific experiments and technology demonstration. During the last years, the number of nanosatellite missions has noticeably increased, posing the need to improve several system characteristics to ultimately endorse the full potential of this class of spacecraft. In this context, this paper presents three design guidelines that can be applied in nano-satellite software in order to improve the system robustness, modularity and autonomy. The design guidelines presented in this paper, namely, hierarchy-enabled robustness, payload-oriented modularity, and on-board planning capabilities, are complemented with a structured review of complementary software techniques and architectural concepts that have been found in the literature. The paper justifies that these system-wide qualities are some of the most critical when designing flight software for CubeSat-like spacecraft and explores how they can improve mission performances and operability, enhance the system's tolerance to failures and ease the development cycles. Finally, this paper illustrates the application of the design guidelines by detailing the on-board software architecture for the 3 Cat-1, a CubeSat program carried out at the Nano-Satellite and Payload Laboratory of the Technical University of Catalonia (UPC BarcelonaTech).

A Highly Modular Software Framework for Reducing Software Development Time of Nanosatellites

“…Several attempts to define a general set of requirements common to all nanosatellites forming the basis of the software architecture have been reported in the literature [4], [13]. The most repetitive features include modularity [1], [3], [14], reusability [2], [5], [11], [15], extensibility [15], [1], portability [5], [15], [14] re-configurability [16], scalability [5], [14], fault tolerance [3], [17], and autonomy [1], [3], [17]. Frequently, the definition of a particular feature varies slightly from one solution to the other.…”

“…The introduction of the CubeSat standard has led to a reduction in the cost, development time, and engineering effort associated with launching these nanosatellites through the standardization of hardware modules and subsystems. However, much less attention has been given to the software architecture, qualities, and characteristics despite their being mission-critical components [1].…”

“…The reasoning should be about vital attributes of the system, including functionality achieved by the system, system's availability in the face of faults, the difficulty of making specific changes to the system, and many others [2]. In the process of pursuing an architectural design to fulfill well-established requirements such as modularity [1], [3], reliability [2], [4], and reusability [2], [5], existing architectures instinctively formed a common standard system of elements. This is demonstrated in Table 1, in which many architectures follow a modular structure.…”

An Architecture-Tracking Approach to Evaluate a Modular and Extensible Flight Software for CubeSat Nanosatellites

“…Following the experiences of similar projects [22], [23] the proposed software design follows the layer architectural pattern dividing the system in hardware drivers, operating system and application layers. This design provides a portable solution [44]- [46] that satisfies the requirement Q4 because the operating system and the device drivers layer can be exchanged by design.…”

“…Without this information it is challenging to evaluate software quality criteria beyond the design phase; moreover, as far as we are aware of, there is not any standard and low-cost methodology to verify software quality criteria for space systems neither in an agile fashion nor in real time. The guidelines provided in Araguz et al [22] represent an important step in this direction. The cFS developers have used, among others, unit testing and graphical tools to verify the architecture and quality of the software [23], [24] but these tools are not continuously integrated into the development process in a way that might allow real time monitoring of the architecture after contribution of different developers.…”