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): [[https://www.esa.int/ESA_Multimedia/Images/2015/08/Mission_control_system][ESA's SCOS-2000]] or from the German Space Operations Center (GSOC): [[https://www.aerosieger.de/images/news_picupload/pic_sid13250-1-norm.jpg][DLR GECCOS]]
** First Screenshots :PROPERTIES: :CUSTOM_ID: first-screenshots :END:
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 [[https://github.com/oswald2/AURIS/wiki][wiki]] for more information.
*** Dark Theme
Telemetry Frame Display:
[[file:screenshots/TMFrames.png]]
Telemetry Packet Display:
[[file:screenshots/TMPackets.png]]
Graphical Parameter Display:
[[file:screenshots/GRD.png]]
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:
[[file:screenshots/Commanding.png]]
The TC History is also very fresh and not completely implemented and does not yet show all necessary information:
[[file:screenshots/TCHistory.png]]
Connections Tab:
[[file:screenshots/Connections.png]]
*** Neumorph Theme
Telemetry Frame Display:
[[file:screenshots/TMFrames_Neumorph.png]]
Telemetry Packet Display:
[[file:screenshots/TMPackets_Neumorph.png]]
[[file:screenshots/TCTab_Neumorph.png]]
[[file:screenshots/TCHistory_Neumorph.png]]
Connections Tab:
[[file:screenshots/Connections_Neumorph.png]]
Configuration Tab:
[[file:screenshots/Config_Neumorph.png]]
** Building :PROPERTIES: :CUSTOM_ID: building :END:
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:
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:
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 :PROPERTIES: :CUSTOM_ID: using-nix :END:
Note: this section must be re-checked!
This project can also be built using =nix-build=. This will use [[file:haskell.nix][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
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 [[file:lorri][https://github.com/target/lorri]] set up, you get this things even set up when cd'ing in this environment!
** Data Processing :PROPERTIES: :CUSTOM_ID: data-processing :END:
The (much simplified) architecture of the data processing backend looks like this:
[[./architecture.svg]]
The real data processing paths (only the core processing, no GUI) that are currently implemented, can be seen here:
[[./figures/data_pipelines.svg]]
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 :PROPERTIES: :CUSTOM_ID: user-interface :END:
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: [[https://github.com/oswald2/AURIS/wiki][wiki]]
** Database :PROPERTIES: :CUSTOM_ID: database :END:
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 :PROPERTIES: :CUSTOM_ID: satellite-information-base :END:
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 :PROPERTIES: :CUSTOM_ID: protocols :END:
The currently working protocols are NCTRS (TC and TM, no ADMIN currently and no AD mode), C&C, EDEN, Generic SIMSAT NDIU Lite Protocol and SLE via ESA's C++ SLE API.
Work has already begun on the implementation of an own native 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: [[https://github.com/oswald2/esa-sle][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 :PROPERTIES: :CUSTOM_ID: notes :END:
** 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 [[https://discord.gg/S7MySPc5EW][Discord]].
See the file [[CONTRIBUTING.md][CONTRIBUTING.md]] on how to contribute.