Month: June 2019

Introduction
On June 18 European Space Agency held a workshop in the Darmstadt, Germany for one of its missions – a relatively obscure yet exceptionally forward-thinking OPS-SAT cubesat [1]. The purpose of this satellite is to provide a platform to run various software experiments in space for interested parties from ESA countries. In other words, it is a software development platform in space – a first of its kind and almost exactly identical in spirit to the cubesat our company is trying to build. 

Mission summary
In terms of actual satellite hardware, OPS-SAT is not a large satellite. It is a 3U cubesat with a mass of around 6kg, with deployable solar panels that can provide up to 24 Watts of electrical power. It will be launched in late 2019 from Kourou space port on a “Soyuz” launch vehicle into a sun-synchronous orbit with 515 km altitude.It has a dedicated on-board computer to run user software and multiple payload instruments, described below:

• On-board computer for user application is an industrial-grade single-board system, with 800 MHz ARM Cortex-A9 CPU and Cyclone-5 FPGA, 1GB RAM and 8 GB of flash memory storage.
• A visible light imaging camera from Berlin Space Technologies is provided, with approximately 80 m/pixel resolution from the mission orbit.
• Fine-guidance attitude control and determination system with a pointing accuracy of <1 deg 
• GPS receiver
• S-band uplink and downlink transceiver
• X-band downlink transmitter 
• A software-defined radio instrument.
• An optical receiver and fused quartz retro-reflectors

Experiments summary
Of course, the most interesting part of this project is what kind of experiments are possible to run on this satellite. As indicated by the project page, over 100 experimenters have signed up for this mission, and a number of those were presenting their concepts during June 18 workshop. The planned experiments can be briefly summarized into the following types:

• Mission autonomy and application of artificial intelligence to spaceflight operations, CNES and ESA itself are very much interested in testing those kind of software solutions, with obvious applications to the next generation of space missions.
• Novel algorithms. Payload instruments, especially imaging cameras, are able to generate large amount of data beyond the capabilities of downlink channel and reducing the raw data to only the most valuable features is a constant struggle for any space mission. So, in-space image processing using ML tools and data compression algorithms were among the popular topics presented. 
• Internal and external communication protocols, including application of IP and HTTP Internet protocols in space environment conditions and implementation of SpaceWire communication bus successor named SpaceFiber, a high-speed internal communication bus protocol over optical and electrical links using FPGA capabilities [2].
• Various radio and optical experiments using onboard radio and optical transceivers, such as SDR spectrum analyser, space-based digital relay, a test of delay-tolerant network for small satellites and test of laser communications using OPS-SAT optical receiver.
• Another group of possible applications were virtualization and user-access share experiments, using Docker and LXC container technology with a potential application as the foundation for “space app” development platform, one of those being a submission from our team, which will be described in more details below

Our contribution
As described on our website, we wanted to build and launch essentially the same satellite mission as ESA, creating a software development platform in space. We are very excited to learn that our vision was also shared by the people working for the major space agency!  For any such development platform to succeed, its software execution environment must have very strong robustness guarantees to handle potentially faulty user code and prevent mission-ending scenarios.

Therefore, our experiment will focus on creating a mission software runtime, that would able to provide the required capabilities. It will be a command language interpreter with a capability of abstracting away the challenges of space environment and nuances of satellite hardware. It’s place in general software hierarchy is illustrated below:

Our experiment has been confirmed to be included in OPS-SAT mission, provided we submit our software package on time. After initial confirmation of its capabilities in space, we want to offer direct access to execute third-party code in our runtime for users through a simple web interface.

The host satellite already provides a lot of necessary functionality in hardware and software including a Java NMF software development framework and fault detection and isolation features, simplifying our mission.  However, our final goal is to build a fully-featured development pipeline on top of this features, including all supporting tools to enable a space application ecosystem, similar to iOS and Android application stores, using our own satellites. 

P.S. You can also read some of the event details from our twitter feed, including video interview from Darmstadt (courtesy of @missmollytv)

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

1. https://www.esa.int/Our_Activities/Operations/OPS-SAT
2. https://ferrous-systems.com/blog/sealed-rust-the-pitch/

European Space Agency offered us an opportunity to present our concept for a chance to test it on the OPS-SAT mission. This is going to happen during their workshop in Darmstadt, on June 18 and the tickets to Germany are already booked!

A few words about OPS-SAT: it is a small satellite, 3U cubesat with the deployable solar panels, fitted with a number of payload instruments such as optical imaging camera, fine-guidance attitude control system, and various radio and optical communication equipment, scheduled to launch in Q4 2019.

OPS-SAT mission is very similar to ours, that is having an ability to safely run third-party software code on its flight computer and use any of the payload instruments. You can read more about OPS-SAT here:
http://www.esa.int/Our_Activities/Operations/OPS-SAT

Our goal is to test a part of our technology, specifically the mission envelope protection middleware that would allow the relatively inexperienced users to safely operate our future satellite in space using the mission software they can develop. Once we can demonstrate that is possible to achieve the required levels of safety and reliability for user software operations, it would be a big step forward to make our goal a reality – to allow anyone in the world to be able to control a real spacecraft in orbit around Earth and beyond!