TDP1 Ground System Design

This paper illustrates the historical development of the TDP-1 ground segment, the system as implemented and operational experience, as well as an outlook to future programs. Aim of the project TDP-1 – Technology Demonstration Payload No.1 - is the demonstration of a data relay service, using an optical High Data Rate Inter-Satellite Link (ISL) between a Laser Communication Terminal (LCT) flown on a low earth orbiting satellite (LEO-LCT) and a second LCT (GEO-LCT) placed on the geostationary communication satellite AlphaSat (of INMARSAT) . The LCT planning system consists of one geostationary satellite (GEO) and up to five low orbiting satellites (LEO) which are also referred to as customers. The main task of GEO within this system is to serve as service provider for the LEOs and one optional optical ground station (OGS). The service consists of an optical data link between the Laser Communication Terminals (LCT) of the satellites (inter-satellite-link,ISL) and a link from a satellite to a ground station (space-to-ground-link, SGL). DLR’s Operations Center (GSOC) role in the TDP-1 program includes design, development and integration of ground infrastructure and operations of the satellites and ground stations. GSOC already gained experience operating Laser Terminals in test scenarios on the TerraSAR spacecraft. This knowledge was be used to develop the TDP-1 operations concept. One major task is the planning of the laser connections and the required coordination between all parties. This paper will illustrate the development from the first activities at GSOC in connection with laser data transfer through the design of the TDP-1 system to an outlook at the EDRS operations concept

A Mobile and Compact Control Center for Quick Decentral Satellite Access

Compact and inexpensive Earth observation satellites in low Earth orbit are now routinely developed by universities, "New Space" businesses, and space agencies. They enable new opportunities for fast turnaround times of imaging data takes, which is e. g. particularly important for disaster response. For this kind of satellites and the missions enabled by them a ground system exhibiting the same characteristics, namely being compact and mobile, yet inexpensive and flexible, is desired. We present DLR's approach for the provisioning of a ground segment fit for the kind of missions outlined above. The objective of this project consists of the engineering, delivery, and demonstration of a compact and yet complete Mission Operations System, runnable on commodity mobile hardware, enabling fully automated workflow-driven operations of alike missions from anywhere in the world with access to a ground station or ground station network. Just as disasters strike suddenly, the ground segment needs to be set up and spun up in a timely manner. This leads to the requirement of being able to quickly roll out the system on new hardware, possibly even several of these systems in parallel. Our paper provides insight on how we perform the automatic deployment and provisioning. Because the system is supposed to be decentralized and used in the field, particular challenges need to be overcome resulting from the lack of all of the infrastructure typically present in conventional control centers, such as network connectivity. An embedded Flight Dynamics system is taking care of automated orbit determination and related event generation to support the mission needs and maneuver capabilities. Special effort is made to cope with auxiliary data that may not be updated on a regular basis in a closed mission environment. The feasibility of the concept is demonstrated by a first system deployment as drop-in replacement for the existing conventional Mission Operations System for DLR's BIROS satellite at the GSOC control center. A second demonstration campaign is performed from a remote location without access to control center infrastructure

Software and Systems

The monitoring and control system (MCS) is the heart of a control center. In this chapter, we focus on the description of this system, since other important software (SW) systems of a control center are described in other chapters of this book. After clarifying some basic MCS terms, the data stream exchanged between the spacecraft and the MCS is explained in more detail. Using the German Space Operations Center (GSOC) as an example, it is shown which SW modules make up the MCS and which SW modules can usefully supplement the operations. An outlook on SW development and maintenance within a control center concludes the chapter

Attitude Control on TET-1 - Experiences from the First Year of Operations

The micro-satellite TET-1 carries several technology experiments. It is the first in a series offering the possibility of in-orbit verification of new equipment made in Germany by the industrial and scientific aerospace community. TET-1 was launched 22nd July 2012 and is operated by the German Space Operations Center. Attitude and attitude control is influenced by several of the experiments. Special attitude control modes are required for a number of experiments in order to point the satellite in a prescribed direction or to a specific location on Earth. These comprise an experiment with three infra-red cameras, a pico thruster and finally a new type S-band transponder. The Li Polymer battery was not expected to have any effect on attitude control. However, it was discovered that charging and discharging the battery disturbs the magnetic field sensors, thus a different approach to attitude control is required when it is in use. implementation of and special demands on the attitude control system for these experiments will be presented. The mission is experimental with high demands on the attitude control system. The envisaged duration was one year only with a possible prolongation of a further year. Components were therefore not chosen for longevity. however, the actual amount of disruptions due to sensor and/or actuator outages and due to idiosyncrasies in the spacecrafts thermal budget was higher than expected. The ensuing challenges for the attitude control system will be discussed. A software upload in May 2013 mitigated several of the issues addressed above. The improvements in the software and autonomous on-board reactions will be presented in the final Section together with some recommendations for the follow-on missions TET-2 and BIROS

OPSWEB - A comprehensive management tool for mission operations

The OpsWeb tool is one of the core applications at the German Space Operation Center (GSOC) when it comes to organizing and supporting multiple satellite missions, presenting quick access to operational data. For the in-house satellite operations, OpsWeb is used to grant permissions for planned and ongoing actions, for reporting, hosting documentation, and providing access to spacecraft and ground segment data. OpsWeb serves as a central hub for easy access to information of other control room software. It is a web based, highly available software solution providing fast and easy access for flight managers and subsystem engineers from the internal networks but also from the internet. In the past years it has been constantly advanced and adopted to new requirements for LEO and GEO missions. The multi-mission OpsWeb provides several reporting tools such as problem reports, pass logs, shift handovers and operational diaries. OpsWeb hosts a large number of operational documents either in a flexible document browser, or special displays for imported flight and ground procedures from PROTOS (a procedure tool developed by GSOC) [1] or MOIS. OpsWeb also enables the subsystem engineers to search the SCOS TMTC database for distinct packages and parameters. Furthermore, the latest telemetry products for LEO missions are hosted by the OpsWeb and can be displayed e.g. labelled by the G/S passes in which they were received. OpsWeb allows the user to gather information from other software tools such as telemetry displays, long-term analysis and visualization tools. Recently, the Operation Support Tools for the Columbus Control Center for the ISS have been integrated into the OpsWeb framework running on dedicated servers, so as to meet the security requirements imposed by the project. OpsWeb is using state-of-the-art web technologies. The streamlined web front-end is designed to minimize the workload for clients with a limited connection bandwidth. It is developed with plain Typescript to avoid unnecessary software dependencies granting long-term maintainability. The backend uses PostgreSQL as a database engine. GraphQL and REST APIs provide the interface between front and backend. Access control is handled by an Open ID connect service simplifying the integration into the pre-existing security infrastructure and adding multiple authentication factors when required. Furthermore, OpsWeb has a well-established backup and fail-over concept with automated live switch-overs in case one of the OpsWeb components goes offline. With future updates, the hosts for the OpsWeb server applications will become platform independent, running on any kind of Linux, Windows or MacOS system. OpsWeb is one of the cornerstones of mission operations at GSOC. It has been used during several LEOPs and supported numerous projects in countless hours of routine operations. It is the main tool to coordinate operations, organize daily tasks, provide quick access to essential information and provide interfaces to other tools in the control room and beyond. The whole OpsWeb framework is easy to maintain and highly adaptable to customer requirements. Moreover, the OpsWeb software is ready to be tailored for the requirements of control centres outside of DLR

A Mobile and Compact Control Center for Quick Decentral Satellite Access

Compact and inexpensive Earth observation satellites in low Earth orbit are now routinely developed by universities, "New Space" businesses, and space agencies. They enable new opportunities for fast turnaround times of imaging data takes, which is e.g. particularly important for disaster response. For this kind of satellites and the missions enabled by them a ground system exhibiting the same characteristics, namely being compact and mobile, yet inexpensive and flexible, is desired. We present DLR's approach for the provisioning of a ground segment fit for these kinds of "Responsive Space" missions. The objective of this project consists of the engineering, delivery, and demonstration of a compact and yet complete Mission Operations System, runnable on commodity mobile hardware, enabling fully automated workflow-driven operations of alike missions from anywhere in the world with access to a ground station or ground station network. Just as disasters strike suddenly, the ground segment needs to be set up and spun up in a timely manner. This leads to the requirement of being able to quickly roll out the system on new hardware, possibly even several of these systems in parallel. Our paper provides insight on how we perform the automatic deployment and provisioning. Because the system is supposed to be decentralized and used in the field, particular challenges need to be overcome resulting from the lack of all of the infrastructure typically present in conventional control centers, such as network connectivity. An embedded Flight Dynamics System is taking care of automated orbit determination and related event generation to support the mission needs and maneuver capabilities. Special effort is made to cope with auxiliary data that may not be updated on a regular basis in a closed mission environment. The feasibility of the concept is demonstrated by a first system deployment as drop-in replacement for the existing conventional Mission Operations System for DLR's BIROS satellite at the GSOC control center. A second demonstration campaign is performed from a remote location without access to control center infrastructure

Battery Operations for the TET–1 Spacecraft

The TET–1 satellite serves as a technology demonstrator within the On-Orbit Verification (OOV) program with the goal of providing German space companies and research institutions with the opportunity to test their equipment on actual spacecraft. It was launched on July 22, 2012, by a Russian Soyuz/Fregat into a Sun-synchronous Orbit with an LTAN of 11:27 UTC. The satellite is powered by nickel-hydrogen batteries during eclipse. The operations team became aware of several issues shortly before and after the launch which created some challenges for battery operation. Some battery cells had undergone reversal prior to launch which seems to have created an imbalance between them. Also, the overall temperature within the satellite and that of the batteries turned out to be higher than predicted and the battery voltage slightly exceeded the limit for payload operations. This paper describes in detail the circumstances in which these issues arose, wherever possible their causes and how they were dealt with. The capacity of the TET–1 spacecraft’s batteries is found to have increased from 12 Ah to about 14 Ah without any significant increase in temperature. Data gained at a later point in time also suggest a positive effect of the reconditioning