A new, open source mission control system in Haskell
A mission control system is the ground software that controls satellites and space probes. An example of an actual operational system can be seen here (example from the European Space Operations Center ESOC, on the monitors): ESA’s SCOS-2000 or from the German Space Operations Center (GSOC): DLR GECCOS
Please note that these screenshots are preliminary. The displays are still subject to major changes, also most implementations are not complete.
There are currently 2 themes available, one dark and one (newer) based on neumorphic principles
See also the wiki for more information.
Telemetry Frame Display:
Telemetry Packet Display:
Graphical Parameter Display:
The commanding interface currently is a very simple implementation to be able to send commands to every interface in the system. The commands currently are specified in textual form, so the GUI for this is minimal:
The TC History is also very fresh and not completely implemented and does not yet show all necessary information:
Telemetry Frame Display:
Telemetry Packet Display:
Currently, building via stack is recommended. Cabal new-* commands should also work, but currently there is no cabal.project file available.
AURIS uses GTK with the gobject introspection bindings in Haskell. So several packages need to be installed beforehand. On Ubuntu based systems these are the following:
- GTK3 + development packages
sudo apt install build-essential libgmp-dev gobject-introspection libgirepository-1.0-dev libgtk-3-dev libgtksourceview-3.0-dev
stack.yaml files provided:
stack.yaml: this is for developing with non-optimized code and faster compile times
stack_opt.yaml: this is for the optimized build (much slower)
stack_llvm:yaml: optimized build via LLVM (much much slower)
stack_sle.yaml: build with the SLE interface. CAUTION: this build requires the ESA C++ SLE API version 5.1.0 (or above) and the sle-wrapper library.
To build it quickly, but without any optimization:
To build with the other options, simply specify the desired stack file, e.g.:
stack --stack-yaml stack_llvm.yaml build
Note: this section must be re-checked!
This project can also be built using
nix-build. This will use
derive nix expressions from the
stack.yaml and then build the local
packages using the same versions as in the stackage
extra-deps. However many of the packages might not be pre-built, but
you can try to use
cachix use iohk nix-build -A esa-space-protocols.components.all ls result/bin # CommandingAD CommandingTest EventLoggingDBTest TMModelTest TMSimulatorTest WriteConfig
There is also a
shell.nix which provides build tools and dependencies
ghcide. Inside the shell you can
stack --no-nix --system-ghc --no-install-ghc,
stack --nix use the
shell.nix (but this requires
your host system).
If you have https://github.com/target/lorri set up, you get this things even set up when cd’ing in this environment!
The (much simplified) architecture of the data processing backend looks like this:
The real data processing paths (only the core processing, no GUI) that are currently implemented, can be seen here:
The automatic layout of graphviz as a bit unfortunate. If somebody knows how to generate a better layout, let me know.
The main interfaces (network interfaces, application interface, GUI) are shown as colored rectangles. Rainbow-colored rectangles show threads, boxes within them show either conduits or functions. STM Queues are shown separate from threads, as (of course) they are accessed from multiple threads.
All data processing is currently done in
which is the main library.
The libraries are designed so that they will be able to be used in a variety of situations: client/server, standalone as one binary, use the libraries alone in other projects etc.
A standalone executable with a GUI is called AURISi (for AURIS integrated) in the ‘aurisi’ directory.
The AURISi executable uses GTK for the graphical user interface.
There is more information available (restructuring and growing) on the Wiki on github: wiki
The initial goal was to support at least 2 backends: sqlite for testing campaigns
and Postgres for MCS/CCS activities. After several tests, the current main backend is
MongoDB, as it showed to be the fastest for the use cases. The current DB backend
implementation can be found in
esa-db-mongodb. If no backend is specified in the
AURISi configuration, it is started just for online processing.
The DB backend is designed for streaming. There are currently three separate store processes (one for TM Frames, one for PUS Packets and one for TM Packets), that just listen on queues, flush the queues if possible (so get all data currently in the queue as a list) and stores them into the DB.
A separate query processor thread is directly attached to the application interface for incoming requests from the outside (currently only GUI). This functionality is currently very sparsely implemented, so retrievals are currently only very limited.
Satellite Mission Information Base
Currently the MIB library is under work to load satellite information from a MIB in SCOS-2000 Format (Version 6.9). Currently, the TM information can be loaded to decode TM Frames and TM Packets, most functionality for extraction is supported (with exception of deduced parameters and synthetic parameters). For commanding, basic TCs can be generated form the MIB, but some parameter types are not yet supported (there are also bugs with calibrated parameters).
It may be, that a CDM library for EGS-CC based configurations will follow (maybe).
The currently working protocols are NCTRS (TC and TM, no ADMIN currently and no AD mode), C&C and EDEN. Since NCTRS is not that common anymore, other protocols will also be supported.
Work has already begun on the implementation of an SLE library, to be able to connect to ground stations without relay/routing software as for NCTRS. The SLE implementation is in a very early state and currently not usable and can be found here: esa-sle This is in a very early state and not usable. An intermediate solution which uses ESA’s C++ SLE API is in work, but this applies to ESA license schemes and will not be present on github.
- The hashtables
library has been forked and directly put into this mono-repo. What has
been modified is that an immutable hash table type has been added (but
only for the Basic ST hash table), which can be obtained by calling
unsafeFreeze. This allows to pass the HashTable out of the ST monad, but also only read-only functions are allowed. Currently, only
- The timer functionality is still undecided. Currently, both
- State machines need more research. Combining state machines with STM and timers is quite challenging. This is needed for the COP-1 machine for AD mode as well as for the Verification timers and the OBQM implementation.
All contributions are welcome, though I am aware that there is quite an entry hurdle as the topic of mission control is a very niche topic and there is not really much broad knowledge available. Things to implement can be found on the Issues page on github. They are often broader topics, which should be split into sub-tasks before. I try to keep them up-to-date as far as possible.
As this is not a simple topic, please ask questions. For issues, this can be directly done in the Issues pages or on the dedicated Discord server for the system Discord.
See the file CONTRIBUTING.md on how to contribute.