Skip to main content

Space Segment Simulator

warning

🚧 This document is still being actively worked on and is subject to change. 🚧

Responsible
  • Kai Berszin
Last Updated10/12/2025, 12:48:54 PM
Last AuthorKai Berszin

Scope​

This document describes the concept of the Space Segment Simulator.
It first reasons the need for such a simulator and will then go into details on what the simulator will entail.
In the last section a brief overview of each component of the simulator is given.

Description​

The Space Segment Simulator shall simulate the SAGE CubeSat as a self contained construct. The Simulator shall have the same informational and physical interfaces (or an emulation thereof) as the real Spacesegment.

The physical hardware connected to the simulator bed may have additional interfaces (such as debug interfaces, probes etc). As these interfaces are not part of this simulator they will not be detailed here.

loading...

Structure​

The Simulator is structured into the Device Under Test (DUT) (i.e. the Space Segment) and a testbench (i.e. the Simulator).

DUT / Space Segment​

The DUT is a subset of the complete Satellite. The subsystems can exist in three states inside the DUT:

  • Hardware - The subsystems EM will be included in the testbench
  • Emulated - The subsystem will be represented by an emulator / mock model in the testbench
  • Partly Emulated - Depending on the developing state / requirements to the simulation:
    • The subsystems EM will be included in the testbench
    • OR: The subsystem will be represented by an emulator / mock model in the testbench
    • OR (ADCS): The subsystem will be partly in hardware partly emulated (Processor in the loop)

The DUT includes the following parts:

Hardware:

Emulated:

Partly Emulated:

Testbench / Peripherals​

The testbench is sourrounded by support equipment / software.

  • EOS/D2S2
  • Software Defined Radio (SDR)

DUT Subsystems​

Emulated Subsystems​

Attitude Determination and Control System (ADCS)​

The ADCS subsystem is represented a DM of a CubeSpace CubeComputer.
The CubeComputer is run in a processor in the loop configuration using either the EOS or D2S2 software provided by CubeSpace.
The software does orbit propergation and keeps track of a simulated attitude. From this it will emulate the ADCS sensor data which is transmited to the CubeComputer.
The CubeComputer executes the control program based on input from the OBC and send actuator commands to the EOS.
The EOS then closes the loop by simulating the actuator behaviour.

Battery Pack (BP)​

The battery pack will either be connected as a physical EM or be emulated by the Battery Pack Simulator (BPS).
The BP can be emulated usig the BPS to be able to use faster than real charging/discharging cycles (-> potentially faster simulation time) as well as to mock various battery charging states.

Biological Payload (PAY)​

The payload will either be connected as a physical EM or be coarsely emulated.
The coarse emulation will only include a data interface responding to CSP messages and allowing the pulling of mock images.

Antenna Deploy Mechanism (ANT)​

The antenna deploy mechanism will either be as physical hardware or be mocked.
The physical hardware can be connected to verify the in-house design prototypes.
For functional tests an emulator can be connected, which will propergate the antenna deploy signal to and the antenna switch state from the Launch State.

Sensor and Power Control Board (SPCB)​

The SPCB will be a hardware / software co-design.
The eFuse, Trikarenos and Temperature sensors will be present in hardware.
The GNSS receiver will be mocked with position data coming from EOS.
TBD: Magnetometer and IMU data will be either implemented in hardware or mocked with data coming from EOS.

Emulated Subsystems​

Solar Panels (PV)​

Due to the high cost and low accessability of light in the lab, the Solar Panels will be fully emulated.
For this one or multiple (TBD) Solar Panel Simulator (SPS) will be connected.
The SPS emulates the charactersiting IV curve of an solar panel taking the current illumiation angle / area as input.

Physical Subsystems​

Onboard Computer (OBC)​

The Onboard Computer (OBC) will be present in hardware.

Power Conditioning Unit (PCU)​

The GomSpace P31u will be present in hardware.
In case of developing activities, the PCU may be functionally replaced by the FlatSat Testing Linecard (FSTL).

Amateur Radio payload (AMPAY)​

The AMPAY will be present in hardware.
The RF interface is connected to a Software Defined Radio either wirelessly using an antenna or an direct attached cable.
In both cases sufficient attenuation must be provided to not damage the RF hardware.

SatNogs Communications Board (COM)​

The SatNogs COMs will be present in hardware.
The RF interface can either be connected directly to an Software Defined Radio or over the RF switches housed on the AMPAY. In case of a direct connection the COM will be connceted either wirelessly using an antenna or an direct attached cable.
In both cases sufficient attenuation must be provided to not damage the RF hardware.

Launch Provider Interface (LP)​

The Launch Provider Interface (LP) will be persent in hardware.
The LP power will be activated depending on the Launch State.

Testbench​

EOS or D2S2​

The CubeSpace Software EOS (or potentially D2S2) will be used to do orbit propagation and attitude emulation.
EOS will use this data to perform Hardware-in-the-loop (Processor-in-the-loop) emulation of the CubeComputer ADCS.
additionally the attitude and orbital position EOS will be feed into the Solar Panel Simulator and to the Software Defined radio to be able to emulate free-space and pointing loss.

Software Defined Radio​

A Pluto SDR will be used for emulating the Ground Segment RF chain.
The orbital position from EOS will be ued to emulate free-space losses.
The Pluto SDR houses two Channels each with a Rx and Tx chain.
Ch0 Rx/Tx will be used for UHF up/down.
Ch1 Rx will be used for S-Band down.

Launch State​

The Launch State keeps track of the physical deployment of the CubeSat.
It contains the state of the Antenna Deployment Mechanism and the state about the ejection from the launch vehicle and thus the launch provider power interface.

Supervisor​

A supervisor will be deploy to unify the various states of the testbench.
The supervisor is capable of resetting each subsystem in a known abitary state.

Open Questions:​

  • Is variable time steps even possible?

Requirements​

  • The simulator must be able to define starting conditions of subsystems

Old notes​

Pipeline:

  • Starting conditions
  • Orbit simulation
  • Hardware
  • Simulation of space segment

Goal is to simulate operations of the space segment using a mix of software and hardware.