Skip to content

Home

Jump to bottom
Michael Oswald edited this page Feb 6, 2021 · 11 revisions

Welcome to the AURIS wiki!

This wiki provides general information about the AURIS mission control system. AURIS is a try to implement typical mission control system (MCS) and central checkout system (CCS) features in Haskell.

DISCLAIMER: knowledge about MCS systems is not something that is available in broad range or can be learned quickly. Therefore, I am very well aware that I am the ‘bottleneck’ in information passing. As the system is developed in my spare time, I also have quite limited time available for sharing knowledge or discussions. I will try my best to be available for questions and discussions on the Discord server, but I may not be always immediately responsive.

That said, lets first give a bit of an overview of the repository.

Quick Start

For the following, it is recommended to build an install AURISi so that there is not so much hassling with command line arguments:

stack install

As a very brief quick start after first compilation of AURIS to see something working:

  1. Start AURISi with an import of the delivered MIB (Mission Information Base). The MIB contains the whole information of the packet structures, parameters, limit conditions and so on for a mission. It can be found in the esa-mib/ASCII_RTE directory.
AURISi --importmib esa-mib/ASCII_RTE
  1. This should startup AURISi, import the MIB and present the graphical user interface.
  2. Change to the TM Parameters tab
  3. On the upper right side click on the New button and select GRD (which means graphical display)
  4. Change the selector on the left side from Displays to Parameters
  5. In the Filter entry below the list enter: S2KTP5
  6. Select the first 2 parameters S2KTP501 and S2KTP502 which represent normal 32 bit and 64 bit floating point values
  7. Right click on them and select Add Parameters to… -> Display 1
  8. This should display the legend for the two parameters in the bottom of the graph, which means they have been added to this graph
  9. In order to see something, we need some real telemetry injected into the system (currently only live data processing is available). For this, open a separate terminal, and open a netcat connection:
cat test-data/tm_dump_signal.raw | netcat -l -p 2502
  1. The folder test-data contains some test files. In this case, we use the tm_dump_signal.raw, which is a noise signal and a sine-like signal on the two parameters we selected above. We pipe this into netcat, which listens on port 2502. This port is configured in the AURISi config file under the setting: cfgNCTRS.cfgNctrsPortTM and specifies the telemetry (TM) port of the NCTRS interface. The dump file is in the NCTRS format, so this is what is used.
  2. AURISi should immediately connect to the netcat instance and get fed with the data, so the signal should appear in the graph. Also the TM Frames tab should display the received telemetry frames and the TM Packets tab should display the received packets.

That’s it for basic telemetry!

Repository Overview

The repository consists of several libraries in a big mono-repo.

  • esa-base: link to wiki page. This is a library where base functionality which is used in multiple other libraries is pulled out in order to break dependency circles between the libraries. All general data structures and functions which are used in multiple libraries need to be defined here.
  • esa-mib: library for loading and parsing the MIB (Mission Information Base).
  • esa-space-protocols: this is the main library doing the whole processing of the protocols used to talk to a spacecraft and/or test equipment. For details see it’s own dedicated page.
  • esa-db: the database interface for permanent storage of the data
  • gui-base: general building blocks for the graphical user interface, used in the other user interface libraries
  • mcs-interface: the primary interface to the processing part (esa-space-protocols). The interface consists of actions which can be triggered by applications and which are transferred to the processing core, and events which are the opposite directions. Events define what happened in the system and applications can register for events to be notified for them. A lot of events are used for data display purposes.
  • auris-tm-displays: telemetry (TM) displays (Frame History, Packet History, Graphical Display, Alphanumerical Display (not yet), Scrolling Display (not yet)
  • auris-tc-displays: telecommand (TC) displays (Stack for sending commands, TC History)
  • auris-control-displays: this is intended for all control displays. Currently only the “connections” display is implemented, but also TC and TM processing settings as well as status displays will be put here
  • aurisi: a single executable with graphical user interface. This is the current main application and is an all-integrated approach, more like a Central Checkout System or a Test System Controller. Evolution will tell if there will be client-server separated interfaces in the future.
  • Chart-gi-cairo: the Chart library is used for displaying the graphical displays. Because of the conversion of the GUI to GTK (gi-gtk) and Chart-cairo uses the gtk2hs versions, which is not maintained anymore, it was necessary to port the Chart-cairo library to gi-cairo, gi-cairo-connector and gi-cairo-render.
  • hashtables-mo: a fork of the hastables package. Additionally contains a freeze function for the hash table, as the hash table is only created once and then only used for lookups and therefore can be accessed from pure code.
  • timer-wheel: a fork of the timer-wheel package. This was necessary as the lates version of timer-wheel removed the create and destroy functions and only provides a with function which only takes an IO function as action to run. AURIS uses internally a mtl based approach (and the RIO monad in the concrete implementation), so the library could not be used. Therefore, a fork was done where the create/destroy functions are available again and can be used within a unliftio based bracket with the RIO monad.

Here is a graph of the dependencies of the libraries:

This is important to know, as this often determines where to put which modules. As haskell libraries cannot depend on each other, this has often design implications. E.g. the division of where modules for the database access are put have to be carefully decided between esa-db, which provides the database functionality, and esa-space-protocols, which actually uses it. Since esa-space-protocols defines some of the data types, which should be stored, but esa-db cannot depend on esa-space-protocols, there are only two solutions:

  1. Put all shared data types into esa-base
  2. As the database types are not directly usable in esa-space-protocols anyway, they have to be converted. So keep the database types in esa-db and the application types in esa-space-protocols and the conversion function is part of esa-space-protocols.

For the system, option 2 was taken for now. There may be refactorings oncoming and data types put to esa-base if this will become a problem.

As can be seen esa-space-protocols is quite the central part, which bundles the main functionality. aurisi then puts all libraries together into a single system, so it naturally has to depend on all libraries.

Clone this wiki locally