From Open Cosmos :: Documentation
Jump to: navigation, search

This document is the qbapp user manual. It describes the main features of the qbapp web application and the possibilities that it offers. The qbapp is a cloud-based web application developed by Open Cosmos to allow customers to:

  • Perform mission analysis studies based on the payload characteristics that the user defines and the platform solution that Open Cosmos suggests.
  • Interact with qbkit in a Hardware-in-the-loop environment where qbkit responds according to an scenario previously defined.

Access to qbapp is restricted to Open Cosmos customers that have already bought qbkit. The credentials to access the application will be delivered during the first Kick-Off call.


In case you have any problem interacting with qbapp, do not hesitate to contact the Open Cosmos customer service (Link to the bug tracking system page).

Login page


The login page is publicly accessible and allows access to the qbapp with the authorised credentials. It is a simple page that requests the user to be identified by providing a Username and a Password. Once the user inserts its login information, it will be redirected to the initial page of qbapp.

Home page

The initial home page is the starting point of qbapp, after the access credentials have successfully been introduced by the user.

The top bar of the home page will always remain on the top and it contains a menu on the right side that allows to go back to the home page or to logout and exit the qbapp at any point. The logo of Open Cosmos in the center can be also used to return to the home page when clicked and there is also a clock whose time format can be selected as: Local Time, UTC, EDT, GMT or EST.

The page is divided in three main sections giving a view for the missions defined by the user and a view for the network of available ground stations (bottom left) and the available launch slots (bottom right).

Home Page.png

Program Overview

The qbapp approach is based on modularity and scalability in the interaction with the customer by introducing the concepts of scenario, mission and space program. All three concepts can be defined and customised by the user depending on the requirements.

A scenario is a set of characteristics that define:

  • The payload interface with the spacecraft platform.
  • The nominal orbit in which the case study is based.
  • The set of ground stations that will be used to download data and telemetry and upload commands.
  • The set of simulation parameters from which the data will be computed.

Scenarios are convenient tools to be able to save and retrieve simulated data. The user is encouraged to perform mission analysis studies by varying parameters of a nominal mission and saving the derived scenarios within the same mission. In this manner, the user can study the interaction of its payload with qbkit for different scenarios without having to change the input values, as explained in the hardware-in-the-loop section.

A mission is, from the qbapp perspective and for this early adopters version, an aggregation of different scenarios. Although it is not necessary, it is recommended that the user takes advantage of this functionality to classify scenarios in different missions according to common characteristics. An example can be a user that wants to study the interface between his camera and the qbkit at different altitudes of a Sun Synchronous Orbit (SSO). In this case, the user may create a mission and aggregate different scenarios whose unique variation is the semimajor axis. If, for any reason, she/he wants to change the type of payload and introduce a scientific experiment and study his interaction with the platform in Polar Orbit (PO), she/he may create a new mission and aggregate different scenarios in a similar way.

A space program is, from the qbapp perspective and for this early adopters version, an aggregation of different missions. This functionality, in this version release, will have no other use than being a tool to organise missions according to their common rationale.


In all levels of the space program structure, the user can either add, modify or delete each element by clicking the plus, the pen and the cross icons respectively.

To access to the detailed definition of each scenario and operate with qbkit, the user shall click in the row corresponding to that scenario. This will guide the user to the development page.

Available Ground Stations

The section of available ground stations provides a list with information of the ground stations that Open Cosmos offer to use during the operations phase.

Available Launch Slots

The available launch slots provides a list with information of the launch opportunities that Open Cosmos offers to place the customer satellites into orbit.

Development Page

Once the desired scenario of the corresponding mission is selected, the user is directed to the development page. The development page is divided into two different sections: The Mission and Systems Design (MSD) section and the qbkit Hardware In the Loop (HIL) section.

MSD - Mission & System Design

The Mission and System Design (MSD) section allows the customer to perform mission analysis studies by running simulations based on the input parameters defined in the Input section. The Input section is divided into two parts. In the left hand side, there is a tool that allows the user to:

  • Define the payload interface with the platform.
  • Define the orbit at which the simulation will run using either TLEs or classic orbital elements.
  • The application allows the user to impose certain configurations in the orbital elements such as Polar Orbits or Sun-Synchronous Orbits.
  • Define the set of ground stations that will be considered to compute data storage memory estimations.


In the right hand side, there is an interactive visual representation of the spacecraft solution proposed by Open Cosmos along with two fields to input the start time of the simulation in ISO 8601 format and the time span of the simulation. In case the user wants to quickly fill up a date in Start Time, it can type “now” on the field to tell the simulator to automatically pick the present date and time.


The interactive visual representation can be expanded to fullscreen and it allows to see the spacecraft in 3D with great detail. Some of the tools include measuring, hiding and measuring elements, explode the model, section views, drawing of different geometries and text, etc.


After filling up all inputs in the Input section, the customer is able to access the results of the simulation by clicking “Simulate Mission”. This will open a new Outputs section where the user will be able to see:

  • World map with the ground track corresponding to the simulation
  • List of eclipses occurred with detailed information of each of them
  • List of ground segment passes occurred with detailed information of each of them
  • Variety of relevant Electric Power Subsystem and On Board Data Handling plots
  • List of mission analysis parameters used in the simulation


Hardware in the Loop

This section allows the user to interact with qbkit in a Hardware-in-the-loop environment where the qbkit responds according to an scenario previously defined.

MSD Tutorial example

This section presents a tutorial example to familiarise the customer with the features that are contained within Mission & System Design.

Scenario: Deployment from ISS

In this scenario, it is assumed that the satellite is released from the International Space Station (ISS) at a specific date and time, T: 01/01/2001 at 16:30:00Z, with the following payload configuration:

  • Average P/L Consumption: 1.3 W
  • P/L Operation: Uninterrupted
  • P/L database generation: 2000 bps

The ground segment supporting this scenario includes TRS and KIR. The scenario will be studied over 1 sidereal day.

The ground segment supporting this scenario includes TRS and KIR. The scenario will be studied over 1 sidereal day.

Input of initial parameters

Within the System tab in the Inputs section of the MSD tool, introduce the following values:

  • Average P/L Power Consumption: 1.3
  • P/L Operation: Uninterrupted (sunlight + eclipse)
  • P/L datarate generation: 2000


Within the Mission tab, ensure the following options are selected:

  • Orbit Configuration: ISS
  • Ground Station(s): TRS and KIR

The MSD offers the option to define the ISS orbit by only selecting ISS in the Orbit Configuration. This will lock all the orbital elements by default.

The Ground Stations selected for this scenario have been chosen so that one has visibility of the spacecraft while the other does not. This will be reflected later on in the results of the simulation.


In the right hand side of the Inputs section, ensure the start time is written down in the following ISO 8601 format standard for dates: 2001-01-01T16:30:00Z and the simulation time is expressed in seconds: 86164 s.


Press the Simulate Mission button to obtain the results of the simulation.

Analysis of output results

As it can be seen in the ground track plot, the ISS orbit has a relatively low inclination (51.6321 deg, as per parameter values defined in the input section). Due to this reason, KIR station does not perceive robust passes with a minimum elevation higher than 5 deg. This can be cross-checked in the Ground Station Passes list of the Mission Events window.


In the Eclipses list of the Mission Events window, it can be observed an initial eclipse that is shorter than the rest of the eclipses. This can be explained by the fact that the simulation starts in the middle of one of them.


Since this early version of the MSD is not attitude sensitive, the result patterns shown in Battery Energy and Generated Power correspond to the patterns to be seen in a constant attitude law. The variation in the sunlight part of each cycle of these graphs is due to the natural transition of the sun vector between the spacecraft faces. The times when both graphs experience a decrease are associated to the times when the satellite is in eclipse.


The implications of selecting P/L Operation: Uninterrupted (sunlight + eclipse) can be seen in the Consumed Power and Generated Data plots. In these plots, constant values for the PL parameters are seen due to the fact payload operations and, therefore, payload power consumption, remain constant regardless of whether they are in eclipse or sunlight.

In the plots below, it is possible to see a deconstruction of the total power consumption of the spacecraft and the total spacecraft generated data into two parts: PL, which stands to payload, and PF, which stands for platform. It is possible to see that, in any point in time, the values of PL and PF always sum the total value of the spacecraft, SC.


Finally, it can be observed how the data within the memory onboard the spacecraft accumulates over time and only reduces when there is a pass over a ground station. Hence, times where the Memory Status graph decreases coincide with the Ground Station passes.