Exodus Orbitals

17^thJuly, 2019

FOR IMMEDIATE RELEASE

Exodus Orbitals Announces Revolutionary Satellite Mission

Exodus Orbitals is pleased to announce their first mission, a “crowd-flyable” CubeSat.

In 2020, citizen scientists, students, and professionals alike will have the opportunity to upload and run their own mission software on an Exodus Orbitals satellite, to put spacecraft subsystems to the test directly in the space environment.

Exodus Orbitals foresees that this revolutionary concept will evolve into a complete development pipeline in space, with:

• Fully-automated building, testing, and deployment facilities.
• An easy-to-use web-based front-end.
• Commercial application development possibilities.

In June, the European Space Agency approved to fly aboard their OPS-SAT spacecraft a piece of critical Exodus Orbitals technology, a hardware-independent software runtime. The OPS-SAT mission is scheduled to launch in late 2019.

About Exodus Orbitals

Exodus Orbitals is a private British-Canadian aerospace company that was founded in 2018. Starting with the launch of their first satellite in 2020, they aim to make participation in space exploration accessible to everyone.

For more information, visit www.exodusorbitals.com or find us on social media – @exodusorbitals

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!

We want to build and launch a CubeSat unlike any other before. 

In addition to the standard necessary subsystems, there will be a dedicated user-accessible on-board computer; through using this computer we will provide access to anyone able and willing to develop and upload their own mission software. This will allow them to control the satellite, commanding spacecraft subsystems and payload instruments to perform tasks within operational safety margins. Such a platform will be the first dedicated to providing an opportunity for the masses to try their skills at software development and mission operations directly in the space environment. 

The primary strength of this mission design is that it will drastically lower the barrier for parties and individuals interested in creating their own projects in space, both financially and logistically. We will also make accessing it as easy as logging into a web server VM. Here is the layout of our system – nothing overly complex:

Of course, things in practice are not as easy as they appear in theory. Inviting people not previously familiar with requirements of software development for demanding conditions of space environment to upload their software to our satellite is a sure way to prematurely end its mission in its first week, if not the hour. So, there is a need to design the entire system in such a way that the probability of such an outcome is minimized. 

Everything matters – from the choice of programming language for the users to the quality of ground verification and validation pipeline and robustness of satellite itself in the case of unforeseen operational scenarios. We will elaborate on those details in the later posts. 

Sounds interesting? Stay tuned

Want more details? Download our whitepaper at https://exodusorbitals.com/files/whitepaper.pdf

Who are the people behind this project? Meet the team: https://exodusorbitals.com/team.html

We are present on social media:
https://twitter.com/exodusorbitals
https://www.instagram.com/exodusorbitals/
https://www.linkedin.com/company/35522580

At the present day, the easiest way to get into space with a small budget and a team of amateur space explorers is to launch a “CubeSat” –a very small satellite, as a cube of 10x10x10 cm dimensions, with larger satellites also possible in the increments of this volume unit. Hundreds of those has been launched since the early 2000s, by universities, smaller aerospace companies or even dedicated individuals. They can carry a variety of instruments and have already proven to be an extremely successful and cost-effective way of doing space exploration activities. You can see their explosive growth curve for yourself:

Image source: Erik Kulu, Nanosatellite & CubeSat Database, https://www.nanosats.eu

However, even the smallest such satellite takes a significant investment of time (on order of years) and money (tens of thousands USD) as well as having to pass regulatory requirements from government agencies and launch providers. These challenges present a significant entry barrier for anyone wishing to launch their own satellite. In addition, even successful launch of a CubeSat is not a guarantee that it will become alive after deployment. The failure rates of those satellites are quite high, and it often takes several attempts to get a reliably operating one in orbit, paying full cost in both time and money each time.

As an example, a 1U cubesat, OSSI-1, was built by a single person, Hojun Song and launched in April 2013. He spent 7 years building it and paid at least $100,000 for the launch alone. Sadly, the satellite never became operational and re-entered Earth’s atmosphere just three months later.

Should not be there a better way?

Space exploration is experiencing a renaissance – with the ascendancy of SpaceX and many of the less prominent but no less motivated independent space companies, ongoing nanosatellite boom, rising ambitions of Chinese Space Agency and the fact that more rockets launched in 2018 than ever before since 1991 the new Space Age is clearly upon us.  

We all have rejoiced watching the successes of the participants – be it the first launch of Falcon Heavy, test flights of new manned spacecraft from SpaceX and Boeing, new Chinese and Indian interplanetary missions as well as many successful NASA and ESA missions.  The privileged few of us have been not just watching, but actively participating in the space exploration research and engineering activities – students, scientists, aerospace industry professionals or civil servants in national space agencies.   

However, the vast majority of people excited about new space adventures have only limited options in doing something space-related. Amateur radio enthusiasts can listen for satellite telemetry and people with data science and programming skills can work with data from satellite instruments. But it takes many years of dedicated training and experience to become an astronaut or aerospace engineer even for most talented people. Similarly, entrepreneurship in space industry requires exceptional level of determination and access to significant capital funds – neither Elon Musk, nor Jeff Bezos didn’t start their companies using just “lunch money”. People in disadvantaged communities and living in countries that lack national space agency or strong aerospace industry are very limited in their ability to contribute to the global space exploration efforts. 

So there is clearly a problem to solve – remove or reduce the entry barriers of modern space industry for people wanting to become part of it, but currently lacking opportunities to do so.

The story of our project began about a year ago, in March 2018 or so, when a group of fellow students doing Astronautics and Space Engineering course at Cranfield University decided to try to identify a good idea for a space startup company. After a few attempts, the idea of a satellite that would allow third-party users to upload and run their software code emerged.

We think it is a excellent idea to try, as this approach can allow anyone in the world to become a space explorer in the truest sense of this word.

We are Exodus Orbitals and our mission is to make space exploration accessible for all people of Earth!