Introduction
Suppose, in a purely hypothetical scenario, that there was a small satellite in space that would allow people on Earth to upload and run their own mission software on its onboard computer. The users would then be able to control the satellite subsystems and operate its payload instruments.
What would be the choice of programming language to allow people to write such software without risking a premature end to the mission? Let’s begin by making some assumptions about the mission requirements.
Requirements
The primary necessity for any language is to match the domain area of the application. Space mission software can be viewed as based on event-driven, state-based architecture with at least part of the code running under hard real-time. Certain mission activities can be performed only under specific conditions, with mission survival taking priority over science or other activities. Therefore, the software development process for a mission needs to produce exceptionally robust code that is expected to perform in both planned and unplanned scenarios. Both the language tooling and semantics must enforce a disciplined approach to the writing of the code part of the software product.
Secondly, satellite on-board computers have increased limitations in available hardware resources in comparison to many terrestrial ones, especially if the satellite in question is a CubeSat with limited power and computing budgets. Effective resource utilisation must be a part of the language features, with direct control over the memory allocation and CPU cycles desirable.
Thirdly, there should be sufficient support for the hardware and software features used on the satellites. If CubeSats are to be considered, then embedded communication buses, such as I2C, SPI, and CAN should be included, together with many different hardware peripherals that may need custom drivers to be implemented. The common operating systems that are used in modern nanosatellites are FreeRTOS and Linux, typically on a type of ARM microprocessor.
Finally, writing the code in this programming language should be fun. We want people without space industry exposure to experience space exploration first-hand; they should not feel discouraged and intimidated by the modern aerospace software development process. The computer revolution of the 70’s and 80’s would not have been possible if the people tinkering with the homebuilt hardware and software were not enjoying doing so. Even though programming a spacecraft is a mission-critical activity, it should not feel painful and joyless if we want a similar revolution to happen in the space industry.
Review
The selection of a programming language for a mission software development kit will be done with the primary intention of allowing people outside of space industry to successfully achieve the quality necessary for flight operation. Minimising the probability of common classes of runtime errors is among the primary requirements. Performance is an important factor as well, due to the nature of a CubeSat flight computer. Taking the above requirements into consideration, the following observations can be made:
- Legacy aerospace languages such as Ada or Fortran, which perform well and are safe enough for space applications, lack the appeal to the modern software developer community. They are not that much fun.
- C or C++ offer good performance and low-level features but are insufficiently safe from common classes of errors, such as memory leaks and buffer overflows. Restricted dialects of these languages such as MISRA-C offer better safety guarantees but present extra entry barriers for the wider audience. They can be utilised but might not be the best possible choices.
- Scripting/interpreted languages, such as Python, JavaScript, and Ruby offer a rich set of features and ease of use, but a potentially insufficient level of performance, real-time guarantees, and embedded programming capabilities. There is a flavor of Python supporting embedded hardware development, but this is still an uncommonly used solution. Those language can be utilized, possibly, but not at the lower end of the space hardware platform.
- Purely functional languages, like Haskell, offer excellent safety guarantees (in theory), as well as good performance, but they are difficult to master for an average software developer, and they offer limited support for real-time programming and embedded hardware, stateful and event-driven software development.
- Modern garbage-collected languages such as Java, C# and Go offer a good level of performance and runtime safety. With some attention to GC behaviour, real-time guarantees are feasible, but support for embedded systems is somewhat limited (less so for Java). Unsurprisingly, Java was selected as the programming language for the European Space Agency’s OPS-SAT [1] mission software development kit that is, in essence, the same as the concept discussed in the introduction. This can be a perfectly acceptable choice for user software, however, there may be an even better choice.
Rust Programming Language Comes Into play
One of the most promising candidates is the Rust programming language. In addition to very strong safety guarantees, it offers modern programming features with an excellent performance level, and good applicability to real-time applications and embedded hardware. The developer community is relatively small, but it is growing rapidly. Furthermore, it offers a good balance of discipline and fun, combining the best features of its ancestral languages together with modern approach to type inference and functional features. There is already a project to create a flavour of Rust programming language explicitly designed for mission critical applications – “Sealed Rust” [2]. Our team will attempt to verify these assumptions during later work, should we be granted the opportunity to flight test our software onboard the OPS-SAT satellite later this year.
What does the Rust community gain from the adoption of their programming language for aerospace applications? While Rust itself offers a lot of advantages for its users, it still faces an uphill struggle in terms of adoption; for most of the common use cases (web and desktop software) its capabilities are a bit of an overkill when compared to already established languages, such as C/C++, Java, Python, PHP, JavaScript, and so on. Embedded hardware development is very conservative, and a lot of legacy code is preventing rapid adoption of new technology but applying Rust to this entirely new domain opens up a growth opportunity offering both greater community adoption and business opportunities for software developers worldwide.
References
- https://www.esa.int/Our_Activities/Operations/OPS-SAT
- https://ferrous-systems.com/blog/sealed-rust-the-pitch/