AURIS

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

First Screenshots

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

More Information

See also the wiki for more information.

Dark Theme

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:

Connections Tab:

Neumorph Theme

Telemetry Frame Display:

Telemetry Packet Display:

Connections Tab:

Configuration Tab:

Building

Currently, building via stack is recommended. Cabal new-* commands should also work, but currently there is no cabal.project file available.

Dependencies

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:

• make
• g++ (libstdc++)
• libgmp
• gobject-instrospection
• GTK3 + development packages

sudo apt install build-essential libgmp-dev gobject-introspection libgirepository-1.0-dev libgtk-3-dev libgtksourceview-3.0-dev

Building with stack

There following 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:

stack build

or:

stack install

To build with the other options, simply specify the desired stack file, e.g.:

stack --stack-yaml stack_llvm.yaml build

Using nix

Note: this section must be re-checked!

This project can also be built using nix-build. This will use https://github.com/input-output-hk/haskell.nix to derive nix expressions from the stack.yaml and then build the local packages using the same versions as in the stackage resolver and extra-deps. However many of the packages might not be pre-built, but you can try to use cachix from iohk:

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 like ghc, cabal and stack and ghcide. Inside the shell you can build using cabal and stack --no-nix --system-ghc --no-install-ghc, or let stack --nix use the shell.nix (but this requires stack on 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!

Data Processing

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 esa-space-protocols which is the main library.

User Interface

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.

More Information

There is more information available (restructuring and growing) on the Wiki on github: wiki

Database

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).

Protocols

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.

Notes

• 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 ilookup, fold and toList are implemented.
• The timer functionality is still undecided. Currently, both updatable-timers and timer-wheel are used.
• 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.

Contributing

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.