GCMS

01. Overview

The Galileo Control Centre (GCC) at Oberpfaffenhofen, Germany ESA/DLR

GCMS (Galileo Constellation Management System) is a real-time operations centre for monitoring and commanding satellite constellations. It provides a unified view of all satellites in orbit, their subsystem health, ground station contacts, and a command interface for satellite operations.

This interface displays live telemetry refreshed at 1 Hz. Orbital positions are computed with a full force model (J2–J6 zonal gravity, F10.7-scaled atmospheric drag, solar radiation pressure with penumbra, and Sun/Moon third-body perturbations). Subsystems model degradation over time: solar panel aging, battery self-discharge, emissivity loss, and reaction wheel saturation effects. Ground station contacts use Friis-equation link budgets, and the radiation/space weather environment is continuously tracked.

What You See

• Constellation view — fleet table, 3D globe, Mercator ground track, and health summary
• Satellite telemetry — drill down into any satellite for subsystem-level detail
• Ground station dashboard — station status, active contacts, and satellite command terminal

Status Indicator

The LIVE badge in the header pulses when telemetry is being received. If it turns red, the connection to the operations server has been lost. The timestamp next to the badge shows the age of the most recent update.

02. Constellation Monitoring

Fleet Table

The fleet table lists every active satellite. Click any row to open its telemetry dashboard. Columns:

Ground Segment

Below the satellite table, a divider row separates the ground segment. Each ground station row shows its name, type, geographic position, and the number of satellites currently in contact. Click a ground station to open its dashboard.

Fleet Filtering

The filter bar above the fleet table lets you filter satellites by orbital plane (ALL / PLANE A / PLANE B / PLANE C). Filtering applies to the table, health stats, and availability calculations. Use this to focus on a specific plane during maintenance or anomaly resolution.

Alarm Summary

The alarm badge next to the LIVE indicator shows the count of active fleet anomalies. Anomalies are categorised as:

• SAFE — satellites in safe mode
• BATT — satellites with battery SOC below 30%
• THR — satellites with thruster faults
• FUEL — satellites with fuel below 10%

Click the alarm badge to highlight the corresponding rows in the fleet table.

Constellation Health

The health score (0–100) in the statistics bar summarises overall constellation fitness:

• −25 per satellite in safe mode
• −15 per satellite with SOC below 30%
• −5 per satellite with SOC below 50%
• −10 if the fleet average SOC drops below 60%

A healthy constellation maintains a score above 90. Scores below 70 warrant immediate operator attention. Per-plane health scores and constellation availability percentage are shown in the statistics strip.

ISL Topology Graph

The ISL button in the statistics strip toggles the inter-satellite link topology view, replacing the Mercator map. Satellites are arranged in three columns by orbital plane (A, B, C) with coloured links showing active ISL connections — green for line-of-sight, grey for no LOS. Hover over a node to highlight its connections, or over a link to see the range in kilometres. This view helps operators identify connectivity gaps or isolated spacecraft.

Telemetry Charts

Click any sparkline in the fleet table to open a 10-minute telemetry trend chart for that parameter. The chart shows the full history buffer with auto-scaled axes, time labels, and a crosshair on hover. Click the overlay background to close it.

3D Globe

The interactive globe uses NASA Blue Marble textures with a day/night shader that follows the Sun’s position in real time. Satellites are colour-coded: blue when sunlit, orange when in eclipse. Ground stations appear as green diamonds with labels. Faint lines between satellites indicate active inter-satellite links.

Click a satellite on the globe to open its telemetry dashboard. Click a ground station to open its dashboard. Hover over either to see a tooltip with key status information. Drag to rotate, scroll to zoom.

Mercator Map

The flat Mercator projection below the globe shows satellite ground tracks as dots and ground stations as green diamonds. Active inter-satellite links appear as green lines connecting satellites. If GPS position is available, your receiver location appears as a labelled marker. A radar sweep animation scans across the map.

GPS Receiver

The GPS panel uses your browser’s geolocation as a ground truth position, then runs a full least-squares pseudorange solver against the simulated constellation to produce a navigation fix — the same algorithm a real receiver uses. Your position is marked on both the globe and the Mercator map, with signal beams drawn to each visible satellite.

The panel displays the following fields when a fix is obtained:

Broadcast Ephemeris

Each satellite generates a broadcast navigation message containing its orbital elements and clock corrections — just like real Galileo I/NAV. The GPS solver uses these ephemeris parameters to compute satellite positions, rather than reading their true positions directly. This introduces realistic ephemeris error (1–5 m) as the broadcast Keplerian prediction diverges from the actual perturbed orbit over time. Navigation messages are refreshed every 30 seconds of simulation time.

Below the GPS fix, a pass predictions table shows the next upcoming satellite passes over your position (see Pass Predictions). Click a satellite name to open its telemetry dashboard.

03. Satellite Telemetry

Click a satellite in the fleet table or on the globe to open its telemetry dashboard. The dashboard shows subsystem panels arranged in a grid. Use the breadcrumb navigation at the top to return to the constellation view.

Orbit

Altitude, orbital period, inclination, RAAN (right ascension of ascending node), sub-satellite point (latitude/longitude), eclipse status, and sun beta angle. The RAAN drifts over time due to J2 perturbation from Earth's oblateness.

The orbit panel also shows satellite metadata from the fleet configuration: orbital slot (e.g. B05), clock type (PHM or RAFS), manufacturer, launch date with age in years, launch vehicle, and launch site. Non-nominal operational status (auxiliary, not in service) is highlighted when applicable.

Power (EPS)

Battery state of charge, solar array power generation, bus voltage, and load consumption. Solar panels degrade ~0.5%/year; battery self-discharge increases with temperature. During eclipse, the satellite runs on battery power; in sunlight, solar arrays charge the battery and power the bus. load_shed indicates non-essential loads have been disconnected to conserve power.

Thermal

Temperature readings (in Kelvin) for each thermal node: OBC, battery, payload, solar panel, and structure. Heaters maintain temperatures within safe bounds. If any node exceeds 340 K, FDIR triggers automatic load shedding.

ADCS (Attitude Determination & Control)

Attitude modes and their operational use:

Reaction wheels store angular momentum on three axes (normalised 0.0–1.0). When any wheel approaches saturation (above 0.95), FDIR commands automatic desaturation using magnetorquers.

Communications

Maximum and effective downlink rate, ground contact status, best elevation angle, contact station type, queued downlink files, and total data downloaded.

Storage

Onboard mass storage capacity and current usage. Files are created by onboard software and queued for downlink during ground passes. The satellite uses a dual-slot (A/B) partitioning scheme for safe software updates.

Propulsion

Fuel mass remaining, delta-V budget, active burn status, and individual thruster health. Supports prograde, retrograde, and radial burns. Each of four thrusters can independently fail (stuck open or stuck closed).

Inter-Satellite Links (ISL)

Number of active ISL peers, link details, and connectivity status. Inter-satellite links require line-of-sight between spacecraft, computed from orbital geometry. Data rate scales with range (1/d²) and is affected by attitude: safe mode disables ISL (can't maintain beam lock), and target-track reduces throughput by ~30%. ISL enables cross-link communication between satellites in different orbital planes.

Processes

A table of all running onboard software processes showing PID, name, privilege role, state, CPU usage, and memory consumption. Click a service name to view its source code.

Event Log

Chronological log of satellite events: mode changes, FDIR actions, ground contacts (AOS/LOS), burns, faults, and software lifecycle events. Events are severity-coded: INFO, WARN, ERROR.

04. Ground Segment

A 20-metre L-band antenna at a Galileo Uplink Station ESA

Station Types

Ground stations serve different roles in constellation operations. The station type determines its function in the ground segment:

Station Capabilities

The dashboard panels available depend on the station type. Not all stations can command satellites — monitor stations are passive by design:

Ground Station Dashboard

Click a ground station in the fleet list or on the globe to open its dashboard. The panels shown depend on the station type (see table above). All stations show:

• Station Info — name, type and description, geographic coordinates (linked to OpenStreetMap), country, and minimum elevation mask. An ESA photo shows the station type.
• Active Contacts — table of satellites currently in view, with name, SVN, elevation angle, contact duration, and a polar elevation chart

Stations with command capability (GCC, ULS) additionally show:

• Terminal — command interface for sending commands to satellites in contact (see Commanding Satellites)

Stations with downlink capability (GCC, TT&C) also provide:

• Onboard Log Viewer — live tail of application logs from the selected satellite

GCC stations have full authority and additionally offer:

Contact Mechanics

A contact begins when a satellite rises above the station's minimum elevation mask (typically 5°). This is called AOS (Acquisition of Signal). The contact ends at LOS (Loss of Signal) when elevation drops below the mask.

For satellites at MEO altitude (~23,222 km), contact passes are long — typically several hours — and multiple satellites are often in view simultaneously. The elevation angle determines link quality: higher elevation means shorter signal path and better throughput.

Link Budget Model

The satellite's effective data rate is derived from a Friis-equation link budget at S-band (2.2 GHz). Throughput scales with the signal-to-noise ratio, which depends on the slant range to the best ground station and atmospheric attenuation:

• Below minimum elevation: No contact — downlink queue paused
• Slant range: Computed from satellite altitude and elevation angle. At zenith (90°), slant range equals the orbital altitude; at the horizon (5°), it can be 3–5× longer
• Free-space path loss: \(\text{FSPL} = 20\log_{10}(d) + 20\log_{10}(f) + 32.45\;\text{dB}\) where \(d\) is the slant range in km and \(f\) is the frequency in MHz
• Atmospheric attenuation: Increases at low elevation angles following an airmass model (\(\sim 1/\sin(\text{elev})\)), adding 0.5–10 dB of loss
• Rate scaling: The excess path loss relative to zenith determines the throughput fraction (5%–100% of maximum rate)

If multiple ground stations are in contact with the same satellite, the station with the highest elevation determines the effective rate.

05. Commanding Satellites

Ground Station Terminal

Satellite commands are issued through the ground station terminal. Open a ground station dashboard (GCC or ULS) and use the terminal panel. The terminal includes a satellite selector dropdown that lists all satellites currently in contact with that station.

Select a target satellite from the dropdown, then type commands in the input field. Commands are routed to the selected satellite and the response is displayed in the terminal output area.

Ground Station Shell

Before selecting a satellite, the terminal operates in ground station mode. This gives you station-local commands for checking visibility, pinging satellites, and connecting to a remote satellite terminal.

Common Operator Workflows

Check satellite health:

status              # Overall status summary
events 10           # Recent system events
fuel                # Propulsion and fuel status
ps                  # Running onboard processes

Manage attitude:

set_mode earth_point                    # Switch to nadir pointing
request_pointing target 48.1 11.3 300   # Point at coordinates for 300s
set_mode sun_track                      # Return to sun tracking
desat                                   # Command wheel desaturation

Manage downlink:

queue_file obs_data 50          # Create a 50 MB observation file
queue_downlink obs_data         # Queue it for downlink to ground

Manage onboard software:

ps                              # List running processes
service list                    # List all services and their states
service restart ttc             # Restart the TTC service
logs 7                          # View output from process PID 7

Orbit maintenance:

fuel                                # Check fuel and delta-V budget
burn prograde 0.5 60                # Prograde burn: 0.5 N for 60 s
burn_abort                          # Abort burn if needed

Set runlevel:

runlevel                        # Show current runlevel
runlevel maintenance            # Enter maintenance mode
runlevel normal                 # Return to normal operations

06. Terminal Command Reference

Complete reference for all commands available in the ground station terminal. Commands are sent to the currently selected satellite.

Information

Filesystem

Program Management

Attitude & Propulsion

Burn axes: prograde, retrograde, radial_in, radial_out

Networking

/ $ ping 5
PING SVN 5 from SVN 1
reply from SVN 5: seq=1 range=450km time=3.2ms
reply from SVN 5: seq=2 range=450km time=3.1ms
--- 4 transmitted, 4 received, 0% loss
rtt min/avg/max = 3.0/3.2/3.4 ms

/ $ trace 5
traceroute to SVN 5 from SVN 1
 1  SVN 2    200 km  0.667 ms
 2  SVN 4    300 km  1.667 ms
 3  SVN 5    150 km  2.167 ms
total one-way: 2.167 ms  rtt: 4.334 ms  3 hops

Storage & Downlink

System

07. Onboard Software

Galileo FOC satellite production line at OHB, Bremen — each satellite runs its own onboard software stack ESA

Quadrate Runtime

Each satellite runs the Quadrate (QD) runtime — a native-code compiler and execution environment for onboard programs. Programs handle satellite operations from power management to telemetry broadcast.

Core Services

These services run automatically and manage satellite operations. They can be inspected, restarted, or stopped via the terminal:

Running Programs

Operators can compile and execute pre-installed programs on a satellite via the terminal. The filesystem is read-only — programs are managed by mission operations.

# Compile, load, and run a program
compile monitor
load monitor
exec monitor

# Verify it's running
ps

//app=hello
//description=Hello World with a custom panel
//role=root
//tick=3000
//cpu=1
//mem=4
//panel=Hello World
//field=counter:float:Counter
//field=greeting:float:Greeting
//render_js=function render_qd_hello(el, data, telem) { el.innerHTML = '<div style="padding:8px"><h3 style="color:#0f0">hello from space!</h3><p>Tick count: ' + (data.counter || 0) + '</p><p>Battery: ' + _ph.bar(telem.batt_soc || 0, 1) + '</p></div>'; }

use xsat
use xsys

fn start( -- ) {
    "hello world started" xsat::log
}

fn tick( -- ) {
    "counter" xsys::get -> c
    c 1.0 + -> c
    "counter" c xsys::set
    "greeting" 1.0 xsys::set
    "hello from space!" xsat::log
}

fn stop( -- ) {
    "hello world stopped" xsat::log
}

function render_qd_<appname>(el, data, telem)
//  el    - DOM element for your panel content
//  data  - object with your UserVars (from xsys::set)
//  telem - full satellite telemetry snapshot

# Compile and run
compile hello
load hello
exec hello

# Verify it's running
ps

// render.js
function render_qd_hello(el, data, telem) {
    var cnt = data.counter || 0;
    var soc = _ph.bar(telem.batt_soc || 0, 1);
    el.innerHTML =
        '<div style="padding:8px">' +
        '<h3 style="color:#0f0">hello from space!</h3>' +
        '<p>Tick count: ' + cnt + '</p>' +
        '<p>Battery: ' + soc + '</p>' +
        '</div>';
}

tar czf hello.qpkg hello.qd render.js

Privilege Levels

08. Fault Management

FDIR (Fault Detection, Isolation & Recovery)

The onboard FDIR service continuously monitors satellite health and takes autonomous action when anomalies are detected:

• Low battery (SOC < 20%) — enters safe mode: load shed, ADCS safe, user apps stopped
• Thermal overtemperature (> 340 K) — triggers load shedding to reduce heat generation
• Reaction wheel saturation (> 0.95) — commands automatic desaturation via magnetorquers
• Thruster fault during burn — aborts the active burn immediately
• No ground contact for > 1 hour — raises a warning event

FDIR events appear in the satellite event log. After safe mode entry, the satellite will recover automatically once conditions normalise (e.g., battery SOC rises above threshold as solar charging resumes).

Fault Injection

For training and testing FDIR response, faults can be injected via the terminal. Use fault inject <type> from the ground station terminal:

Example: Power Anomaly Response

# Inject a power drain
fault inject power_drain

# Watch FDIR respond
events 5

# Monitor recovery as solar charging restores SOC
status

09. Pass Predictions

How It Works

The pass predictor uses a simplified J2 orbital propagation model to forecast when each satellite will be visible from your location. It steps forward in 30-second increments over a 24-hour window, computing elevation angles at each step.

A pass begins when a satellite's elevation rises above 5° (AOS) and ends when it drops below 5° (LOS). The moment of peak elevation is recorded as TCA (Time of Closest Approach).

Prediction Table

The pass predictions table appears in the GPS panel and shows the next 10 upcoming passes, sorted by AOS time:

J2 Propagation Model

The predictor accounts for the Earth's oblateness (J2 perturbation), which causes RAAN precession and argument of perigee drift. This gives more accurate predictions than a simple Keplerian model, especially over a 24-hour window. Orbital elements are fetched from each satellite's live telemetry.

10. Fleet Operations

Multi-Select

In the constellation view, use vim-style keyboard navigation (j/k to move, g/G for top/bottom, Enter to open a satellite). Press Space to toggle multi-selection on the highlighted row. Selected satellites are highlighted in the fleet table.

Operations Toolbar

When one or more satellites are selected, the operations toolbar appears below the fleet table showing the selection count and three dispatch buttons:

• SHELL CMD — prompts for a command and dispatches it to all selected satellites in parallel
• SAFE MODE — sends safe-mode enable to all selected satellites (with confirmation)
• DESAT — sends adcs desat to all selected satellites

Press CLEAR to deselect all satellites and hide the toolbar.

Command Queue & Macros

The macro toolbar appears below the terminal input. It lets you batch commands and save reusable sequences.

• QUEUE — toggles queue mode. When active, pressing Enter adds the command to the queue instead of executing it immediately. Queued commands appear as a numbered list above the input.
• RUN QUEUE (N) — executes all N queued commands sequentially with a short delay between each
• SAVE MACRO — prompts for a name and saves the current queue as a reusable macro
• LOAD MACRO — dropdown to select a saved macro, which loads its commands into the queue

Macros are stored in your browser’s local storage and persist across sessions. Use the dropdown to manage saved macros.

# Toggle QUEUE mode on, then type each command:
status
events 5
fuel
ps

# Click SAVE MACRO, name it "health_check"
# Next time: LOAD MACRO → health_check → RUN QUEUE

11. Module Packages

Overview

The .qpkg package format bundles a Quadrate program with its dependencies and optional UI components into a single archive. This allows operators and third-party developers to distribute self-contained modules that include source code, library files, and custom panel renderers.

Package Structure

A .qpkg file is a gzip-compressed tar archive containing:

Additional files (README, assets, etc.) are ignored by the parser but preserved for forward compatibility.

Manifest Directives

The main .qd file must contain standard manifest directives as comments. These define the module's identity, resource requirements, and optional UI panel:

//app=battery_guard
//cpu=5
//mem=16
//tick=2000
//perms=telemetry.read
//description=Monitors battery health and triggers load shedding
//panel=Battery Guard
//field=soc:bar:SOC:%
//field=voltage:float:Voltage:V
//render_js=inline JS here (or use external render.js)

fn start() { }
fn stop() { }
fn tick( -- ) { }

Creating a Package

Use standard tar and gzip tools to create a .qpkg archive:

# From your module directory:
tar czf battery_guard.qpkg main.qd render.js lib/

The archive must have the main .qd file at the root level (not inside a subdirectory). Library files go under lib/.

Size Limits

Listing Modules

# List installed modules:
curl http://127.0.0.1:<port>/api/v1/modules

On-Satellite File Layout

After installation, files are stored in the satellite filesystem:

API Reference