Content uploaded by David Evans
Author content
All content in this area was uploaded by David Evans on Jan 03, 2018
Content may be subject to copyright.
American Institute of Aeronautics and Astronautics
1
OPS-SAT: Operational Concept for ESA’S First Mission
Dedicated to Operational Technology
David Evans1 and Alexander Lange2
ESA/ESOC, Darmstadt, Germany, D-64293
This paper describes the unique mission concept of the ESA OPS-SAT project. OPS-SAT
is ESA’s first nanosatellite mission and is the first mission world-wide to be designed
exclusively to demonstrate ground-breaking satellite and ground control software under real
flight conditions. The project is being led by the European Space Operations Centre (ESOC)
in Germany which has recognised the need to try something very different to break out of
the “has never flown, will never fly” cycle in the mission control domain. The project is
presently in Phase C and will launch in Q3/4 2017. The concept is unique in several ways not
least because it involves replacing the entire on-board software suite, right down to
operating system, on a daily basis. This also extends to the ground system which must be
designed to be replaceable on the same time scales. The satellite has to remain safe even
though it is recognised that with little time for minimal preload testing, the ground and on-
board software will contain dangerous bugs. The concept also has to deal with the inevitable
consequences of single event radiation effects on the commercial off-the-shelf hardware and
software selected. Finally the mission has to provide and unprecedented levels of
configurability to allow as many experiments to run as possible. In this paper we will also
describe how ESOC intends to interact with the experimenters. There are presently over 100
experiments registered for the flight and this number is expected to grow as we approach
launch. The challenge is how to deal with this number of experimenters and keep the
operations as low cost as possible.
I. Introduction
PERATING a space mission is not easy. The space environment is terribly unforgiving and it is not the ideal
place to be testing new pieces of complicated bespoke hardware or software. Mission critical software, both
on-board and on the ground, is therefore selected for its proven, rock-solid reliability rather than other
considerations. This results in resistance to experimentation and innovation, especially when the projected benefits
are not yet flight proven. This leads to the “has never flown, will never fly” cycle. Time after time projects settle for
reuse rather than innovation.
Nowhere is this truer than when dealing with the interface between the spacecraft and ground control. ESA is
still using the Packet Utilisation Standard (PUS) as the main application level software interface to control their
satellites. The PUS was issued in 1994 i.e. before MP3 players and DVDs existed. While terrestrial interface
software has changed enormously in the last twenty years, it has remained static in the space world. The fact that
nothing has changed for a long time does not mean that proposals to evolve the control interfaces between mission
critical software are not made. On the contrary there is a wealth of patents, innovative applications, new standards
and concepts that have been pro-posed over the years. They just never fly.
At the European Space Operations Centre (ESOC) based in Darmstadt Germany the need to break out of this
cycle has been recognized and the OPS-SAT mission has been created de-signed specifically to do just that. We
believe that having a mission exclusively dedicated to operations technology is a world first. As the space segment is
based around a 3U Cubesat, it also marks ESA’s first full entry into the emerging nanosatellite world.
The mission has an open door policy and extremely light application process for experimenters. This means that the
project will not request documentation or reviews of the experiments before execution, we will simply make a quick
test of the experiments to make sure some simple FDIR rules are followed and then load it. The idea is to remove the
barriers to experimentation in the area of operations and this includes not only risk but also cost and documentation
1 Project Manager, Special Projects Division, ESA/ESOC, Darmstadt, Germany.
2 Project Assistant, Special Projects Division, ESA/ESOC, Darmstadt, Germany.
O
Downloaded by 191.101.64.122 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2354
SpaceOps 2016 Conference
16-20 May 2016, Daejeon, Korea 10.2514/6.2016-2354
Copyright © 2016 by European Space Agency.
Published by the American Institute of Aeronautics and Astronautics, Inc., with permission.
SpaceOps Conferences
American Institute of Aeronautics and Astronautics
2
overload. This approach has attracted considerable interest and we now have over 100 experiments registered for the
flight and this number is expected to grow as we approach launch. At the same time we have very little budget for
operating the space, ground and experiment segment which poses some fundamental challenges. This paper
describes how ESA intends to address these challenges. It starts with a description of the mission history,
requirements and experiments registered so far. Then it addresses the space segment before moving on to how we
will deal with all these experiments operationally with very little budget.
II. Mission History
OPS-SAT is an ESA nanosatellite mission designed exclusively to demonstrate ground-breaking satellite and
ground control software under real flight conditions. This makes it the first mission of its kind worldwide. The
project is being led by the European Space Operations Centre (ESOC) in Germany underlining it as a mission
designed by operators for operators.
In 2011 the Advanced Operations Concepts Office at ESOC proposed the concept. In January 2012 the ESA
General Study Programme funded a feasibility study using the ESA Concurrent Design Facility in ESA/ESTEC. At
the end of the concurrent design sessions, the design team declared the project feasible with a preliminary design
based on a 3U Cubesat.
Following the study, the ESOC team was contacted by many companies and other national space agencies who
expressed an interest in flying their experiments on the satellite. In March 2013, ESA released an open call for
experiment ideas. The response was overwhelming with over one hundred experiments from 17 Member States
being selected for the next stage. This response was enough to convince the ESA General Support Technology
Programme (GSTP) to open a call for Member States to fund the next mission phase. Austria, Germany and Den-
mark responded positively
The project then kicked off two parallel Phase AB1 studies, starting in July 2013, supported by GSTP. These
were led by the Institute of Communication Networks and Satellite Communications of TU Graz (Austria) and
GOMSpace of Denmark respectively. TU Graz was supported by Zentrum für Telematik and GOMSpace by GMV
GmbH both in Germany.
Following completion of Phase AB1, TU-Graz put together a consortium and proposal to take the mission
through Phase B/C/D/E. Poland joined as a supporting member state. GSTP then approved the entire mission and a
consortium of the following companies led by TU Graz won the contract to design, test and build OPS-SAT. TU-
Graz, MAGNA STYER & UNITEL (Austria); GOMSpace (Denmark); MEW Aerospace UG and Berlin Space
Technologies (Germany) and finally SRC and GMV Innovating Solutions (Poland). Core avionics are delivered by
GomSpace with core software from GMV. Notable hardware payloads are the advanced ADCS and camera for
Berlin Space Technologies, a software defined radio and optical uplink receiver from MEW Aerospace, a CCSDS
compatible TMTC decoder/encoder from SRC and a X band transmitter capable of transmitting at 50 Mbps from
Syrlinks, France.
The mission CDR phase is on-going and planned to be completed in April 2016. Launch is planned for the
second half of 2017.
III. Mission Requirements
The objective of the OPS-SAT mission is to drastically improve ESA mission control capabilities by providing
an in-flight experimentation platform on which European industry and academia can explore the opportunities that
arise when present barriers are removed. These barriers are the present low computer processing capabilities on-
board satellites and the strict requirements on pre-flight testing/heritage imposed on mission critical software.
The mission will explore these opportunities by launching a low cost, low risk, experimental platform that flies
the latest miniature processor hardware and reconfigurable firmware. Experimenters will be able to reconfigure any
part of the end-to-end chain on ground or on-board to demonstrate new operational concepts under flight conditions
The OPS-SAT spacecraft will be designed to be extremely robust, in the sense that it can survive any possible
impact caused by incorrectly running experimental software. It will be able to survive until contacted by the ground
and then being recovered for the next experiment.
The driving requirements are as follows:
1) OPS-SAT shall allow experimentation with on-board and ground software by offering a safe and
reconfigurable environment for execution of software experiments that are relevant for future mission
operation needs at ESA.
Downloaded by 191.101.64.122 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2354
American Institute of Aeronautics and Astronautics
3
2) The spacecraft shall be power and thermally safe even if tumbling. The mission shall be robust against
single event upsets, latching events or faulty experimental software. It shall be demonstrated that despite
using COTS components a reconfigurable and yet re-liable platform can be delivered.
3) The OPS-SAT payload shall deliver as a minimum; two processors running at 500+MHz with 500MB
of RAM, 10 GB solid storage and a reconfigurable FPGA.
4) Software experiments shall have open access to all on-board resources and systems un-less justified due
to safety.
5) At least one configuration shall be representative of an ESA mission (including ground software and
OBSW).
6) S-Band uplink rates of at least 256 kbps and S-Band downlink rates of 1 Mbps shall be supported. The
high uplink data rate is due to the fact that this mission is focused on new software experiments.
Therefore it is needed to upload the frequently changing software experiments in reasonable times.
7) The spacecraft shall be recoverable and resettable by at least two independent communications routes in
hardware and software. The spacecraft shall be able to communicate with the respective ground station
in any orientation
ESA and its European industry partners generate every year many new and innovative ideas for advancing
European space technology regarding mission operations but the majority of these innovations never make it to
orbit. OPS-SAT emerged, providing a low cost in-orbit laboratory available for authorized experimenters to test,
demonstrate and validate their development software experiments. OPS-SAT is the first CubeSat designed by ESA
and is a safe experimental platform which shall fly in a low-earth sun synchronous orbit. OPS-SAT makes available
a reconfigurable platform, at every layer from channel coding upwards, and it will be available for experimenters
wishing to test and demonstrate new software and mission operation concepts.
IV. The experiments
During the CDF preliminary design, requirements for the mission were based on the following ESOC and CNES
experiments:
• CCSDS Mission Operations Services
• File-based Operations
• Autonomy Operations and Opportunistic Science
• Housekeeping Telemetry Compression
• Deployment of Drag Enhancement Device
• CNES Miniature X-Band Transmitter
In May 2013, the ESA General Studies Programme supported ESOC in arranging a call for ideas for OPS-SAT
experiments. The idea was to gauge the need in Europe for such a flying laboratory. The response from industry and
academia was an overwhelming yes. The range of the experiments submitted covered every aspect of mission
control and the experimenters themselves ranged from small start-ups with no space experience to large primes. An
ESOC industry day to discuss these requirements in May 2013 was attended by over one hundred delegates.
After initial screening over 100 experiments were shortlisted from that call to provide requirements. The
response is even more remarkable considering that fact that the project explicitly stated beforehand that no project
funding would be made available for experimenters. In return the project would not impose overheads on the
experiments such as documentation etc. They would be expected to deliver on-board bootable images and the only
restriction would be that these would have to pass a safety test before they would be uploaded. This implies that the
most of the experimenters will have to self-organize in order to create working configurations of ground and on-
board software.
The experiments are listed below by focus area:
High level applications: Ship tracking, monitoring (motorway, pirates, containers, ships, waves etc.)
Support applications: Planning and scheduling, super resolution, compression, encryption, goal based
automation, advanced on-board image processing
Downloaded by 191.101.64.122 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2354
American Institute of Aeronautics and Astronautics
4
Middleware software: Novelty detection autonomy, in-orbit troubleshooting applications, new SEU error
detection and correction schemes, redundancy schemes to increase reliability of FPGA operation, fault mitigation
schemes, new anomaly detection schemes in time series data, autonomous diagnostics.
Basic software: Cloud in space, basic software provision, time/space partitioning, new PUS standard, new
CCSDS MO services, in-orbit building of OBSW, SOIS, self-adaptive systems, FDIR frameworks, testing LISP for
OBSW,
ADCS: Precise attitude monitoring of a free flying object, EUROSIM in space (formation flying test), enhanced
GPS satellite selection, simplified ground interfaces for ADCS control, particle filter localization (sensor fusion),
ADCS system using on-board adaptive neutral network, precise attitude determination using laser pulse
measurements, attitude determination based on image recognition, non-linear model predictive control of slews.
Network/protocols/communications: New channel coding schemes, IP in space, Delay Tolerant Networks, TCP
in space, experimental high speed on-board network, optical downlink, optical uplink, CFDP
Ground systems: New data distribution tools, benchmarking of different ground systems on the same mission,
demonstration of distributed ground station network.
End to end operations: Distributed operations, switching between teleoperation and autonomous camera
operations, mobile field operations, multiplexing command and control with telecom payload channels, transparent
space services, distributed applications (ground and space), File based operations, operations with limited ground
database, predictive schemes to enhance robotic teleoperations, web based operations, flying an on-line web service
for the camera operations, distributed procedure execution using MOIS (on-board and on the ground).
Development: Concurrent design in full lifecycle, TASTE in Space, using state of the art software methodology
for OBSW development, continuous integration of OBSW
Hardware: Star tracker, hyper spectral camera, optical uplink, software defined radio, LEO-LEO links, mini X
band transmitter
The analysis of the experiment requirements highlighted that significant improvements in some areas would be
needed if the mission was to be able to support the majority of these experiments. This was especially true in the
areas of processing power, on-board memory, ADCS performance, camera resolution and configurability.
V. The Space Segment
OPS-SAT can be viewed as four interconnected parts: a cubesat bus, an ESA communications module, a payload
and a FDIR system. The payload can be further broken down into a processing core, various peripherals (camera,
GPS, advanced ADCS subsystem) and several payloads of opportunity. The cubesat bus consists of an on-board
computer called the Nanomind, a power subsystem, a UHF communications subsystem and a basic ADCS
subsystem.
The mechanical architecture of the OPS-Sat is a 3U CubeSat structure with double folded deployable solar
panels. It has a size of 10x10x30 cm (not including deployable) and a mass of approx. 5.4 kg. Two deployable solar
array panels generate 30 W of electrical (peak) power. The spacecraft outside front view is shown in Fig.1, while the
rear view is shown in Fig.2.
Downloaded by 191.101.64.122 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2354
American Institute of Aeronautics and Astronautics
5
A. Bus
Approximately 1U of the satellite accommodates the cubesat COTS components, including: the UHF antenna
deployment system (as well as the software defined radio receiver payload antenna, see later), a motherboard with
the UHF transceiver, the NanoMind OBC, the BP4 battery pack with 4 battery cells, the EPS system, consisting of a
motherboard accommodating two power input boards for the body mounted and deployable solar array strings, and
two power output boards for power regulation and distribution and the Z axis magnetorquer integrated in a PCB.
The double deployable solar arrays are provided by ClydeSpace whereas the remaining components are provided by
GomSpace. Using a quasi-single provider keeps the integration costs and risks of the satellite bus low. GOMSpace
also provide the ground terminal for the UHF communications. The one area where some development was required
on the COTS components was the power conditioning subsystem. The mission sometimes generates over 30 W of
peak power and is connected in 11 strings. To accommodate this GOMSpace proposed an architecture with two
separate power conditioning and distribution boards, each connected to half of the solar arrays on the satellite. Solar
arrays cover the satellite except for the Z faces, as shown in Fig. 2. The deployable solar arrays have integrated sun
sensors and magnetorquers. The bus also includes a GPS unit which is linked to the NanoMind OBC to provide GPS
functionality to the ADCS system. The GPS antenna is integrated into the –X panel next to the umbilical connectors
of the spacecraft. As the GPS will be integrated with the CubeSat bus and not directly to the processing platform, all
data from the GPS can be made available over the I2C payload bus interface from the NanoMind to processing
platform. In addition, the GPS will be used for timekeeping on the Nanomind OBC, which keeps the on-board time
(OBT).
A driving mission requirement is that a satellite configuration should exist that is indistinguishable to the ground
from a typical ESA satellite. Among other things this means that the spacecraft has to fly firmware and software that
implement CCSDS protocols. The solution is to deploy the IP core of an ESA TM/TC encoder/decoder chip onto a
commercially available FPGA. This unit is referred to as the CCSDS engine. This chain will be used for nominally
communicating between the Nanomind OBC and the ESA ground control system. However it will be possible for
the experimenters to bypass this unit and go directly between the S band transponder and the SEEP. This will allow
configurations that use non-CCSDS protocols such as TCP/IP on the mission.
Since over 90% of the experimenters want to load large software images to the spacecraft as part of their
experiment it was decided that the mission had to allow the fast upload. The S-band receivers must therefore be able
to accept an uplink signal at 256 kbps. For comparison the UHF transceiver on the Cubesat bus can only support
data rates of 9.6 kbps. This is much higher than the highest uplink rate for normal ESA spacecraft which is 4 kbps
rising to a maximum of 64 kbps in some rare cases. This requirement is already driving innovation on the ground as
during ground prototype testing ESA realized its ground segment could not pro-duce such a fast telecommand
stream without major modifications. This presents us with a prime example of the nanosatellite world challenging
long standing and accepted limitations in the world of big space. On-board the new EWC31 S-band transceiver from
Syrlinks, France has been selected to provide this high uplink and a variable downlink rising to 1 Mbps.
Figure 2. OPS-SAT rear view.
Figure 1. OPS-SAT front view.
Downloaded by 191.101.64.122 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2354
American Institute of Aeronautics and Astronautics
6
B. Satellite Experimental Processing Platform (SEPP)
The Satellite Experimental Processing Platform (SEPP) is the heart of the OPS-SAT payload. It is a powerful
ALTERA Cyclone V system-on-chip module with sufficient on-board memory in order to carry out advanced
software and hardware experiments. It is the reconfigurable platform required on OPS-SAT on which all major
experiments will be processed. The Altera Cyclone V SX System-on-Chip (SoC) digital core logic device provides
with a 800MHz CPU clock and 1GB DDR3 RAM a powerful processing capability. All Altera SoC SX devices
consist of an internal Hard Processing System (HPS) and a Field Programmable Gate Array (FPGA) portion. The
Altera Cyclone V SX SoC HPS is a fully functional computer and contains a dual core ARM CPU with several
built-in hardware blocks and device interfaces. It also has built-in error correction coding (ECC) features..
The system offers the possibility to use DDR2, LPDDR2 or DDR3 RAM. The ARM CPU is connected to a large
number of HPS hardware blocks. Bridges enable high speed data exchange between FPGA and HPS portions. Linux
is used as default operation system (OS) for the SoC. All HPS blocks can be accessed from the installed OS
application software. The HPS portion has to be configured at system startup. The SoC configuration data is part of
the SEPP software image stored in the external memory. The image is based on the Altera reference Yocto Linux
and U-Boot boot loader software.
C. Fine ADCS
OPS-AT contains two ADCS systems. One is provided as part of the bus and is referred to as the coarse ADCS.
The control algorithms are implemented on the Nanomind OBC and it relies on magnetotorquers as actuators and
sun sensors and magnetometers as sensors. The other is implemented as part of the payload and is referred to as the
fine-pointing ADCS or iADCS. Experimenters can use this for carrying out attitude control experiments and to
provide higher pointing accuracy for camera and optical data transmission experiments. Control algorithms can be
placed directly on the iADCS FPGA or on the SEPP. The iADCS-100 by Berlin Space Technologies has been
chosen allowing a pointing accuracy well below 1°. The iADCS provides a set of high performance sensors and
actuators such as the ST-200 star tracker and miniature reaction wheels. In combination with the proven ADCS
algorithms derived from the renowned TUBSAT satellites, the iADCS-100 offers a number of autonomous modes
such as nadir pointing and target pointing that were before only available for larger spacecraft.
The evaluation of the experimenters’ proposals showed that there is significant interest in camera experiments.
Several experimenters will develop on-board processing algorithms for simple remote sensing applications.
D. Camera
The baseline for the OPS-SAT optical camera is the BST IMS-100. This is a small space camera developed by
Berlin Space Technologies based on the ST200 star tracker. The ST200 has been developed and tested for the Earth
Video Camera project for the International Space Station. Sensor and MCU have been tested with proton irradiation
of 130MeV for a TID of 10 krad. It can provide still images as well as video, whereby image processing will be
performed on the processor core (SEPP). For video download the X-band transmitter will be used. The camera
performance is provided in the following table:
Parameter
Value
Comment
Resolution
53m
@ 600km orbit height
Field of View / Scene
135x105km
@ 600km orbit height
Channels
3
RGB via on sensor Bayer
Pattern
Frame Rate
7 / 15
2600x2000pixs / 1300 x 1000
pixs
Table 1. IMS-100 Camera Performance.
Downloaded by 191.101.64.122 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2354
American Institute of Aeronautics and Astronautics
7
E. Syrlinks EWC27 X-band transmitter
This CNES funded mini X band transmitter from Syrlinks, France is capable of transmitting up to 50 Mbps. It
was subsequently selected to fly because it has a great deal of synergy with the other experiments. The on-board
camera will support both still image and streaming video modes and many experiments intend to exploit this. Such
camera experiments will require substantial downlink data rates for which the EWC27 X-band transmitter will be
needed, particularly when bearing in mind real-time applications and the short contact times (typically 10 minutes
for a ground station pass, four times a day). In fact the EWC27 has already flown as part of the ESA/GOMSpace
mission GOMX-3 which was re-leased from ISS on August 19th 2015. The unit has already been tested successfully
at its maximum limit of 3 Mbps (due to ITU regulations).
F. Optical Receiver
This optical communications experiment will see an optical uplink for the first time on a nanosat. It provides a
transmission rate of 16 Kbps using a small optical receiver which fits into OPS-SAT. A photon counting module
with a built-in multi-pixel photon counter is the heart of this system. A prototype of the receiver was tested on
ground and it was demonstrated that transmissions with the specified data rate can be carried out. For the uplink the
Satellite Laser Ranging Station operated by TU Graz and the Space Research Institute of the Austrian Academy of
Sciences at the Lustbühel Observatory shall be used. The optical receiver will be connected to the SEEP so that
uplink data can be received and processed by on-board experimental software. The laser ranging station at TU Graz
will be used as the ground segment for the experiment. The laser ranging station at TU Graz will be used as the
ground segment for the experiment. Optical retro-reflectors on the surfaces of the nanosatellite will provide the
means to locate and track the spacecraft by laser tracking & ranging stations, assisted by an on-board GPS which is
integrated in the core avionics.
An interesting aspect of the experiment is that this will be the first time a nanosatellite has been communicated
with via an optical channel. Also the application will allow the secure uplink of one-time pad encryption keys. These
can be used on the RF downlink making the broadcast extremely secure. Such an experiment has never been done
before.
G. Software Defined Radio Frontend
This is a very small radio front-end consisting of a tuner, down-converter and analogue to digital converter.
Complex signal samples are delivered to the SEEP where signal processing (e.g. demodulation and decoding) can be
performed by on-board experimental software. This allows the monitoring and demodulation of radio signals for a
wide frequency range. This range includes the radio amateur UHF bands and this community has indicated interest
in using the mission to perform a spectrum survey of those bands to investigate the increasing interference problems
in uplink.
H. Optical Retro-Reflectors on Panels for Attitude Determination
This passive experiment will allow attitude monitoring and precise tracking using laser stations on the ground.
There is an interest, especially among the space debris community to investigate the spacecraft dynamics of
asymmetric objects such as OPS-SAT when uncontrolled. This can be done on this mission by simply disabling the
actuation for periods when the mission is running and after mission termination using the laser reflections to
determine attitude sate and evolution as it slowly descends.
VI. Mission Operations Concept
The main problems the OPS-SAT mission concept had to solve are listed below along with a brief description of
the solutions.
Problem: Limited budget for spacecraft operations
Solution: Concentrate on ensuring the space segment is safe at the expense of mission return. Ensure the on-
board system is always recoverable via multiple RF routes. Provide a robust, simple safe mode with clear simple
entry criteria. Ensure the spacecraft is power and thermally safe even when tumbling. Provide full automation of
ground. Ensure the mission planning is kept very simple at the expense of mission return. Provide a large on-board
data storage and high speed downlink removing time constraints on dumping data to the ground.
Downloaded by 191.101.64.122 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2354
American Institute of Aeronautics and Astronautics
8
Problem: Limited budget for operations preparation
Solution: Provide a simple script approach for procedure creation that has automation as a goal from the start.
Use exactly the same procedure system as the AIV team. Exploit the small size of the satellite to perform open field
tests with the satellite itself and ground segment. Exploit the low cost nature of the space hardware to deploy copies
very early at ESOC for parallel testing with the AIV team.
Problem: Limited budget for ground segment preparation.
Solution: Perform in house development of the ground segment integrating components from different studies
and infrastructure while limiting changes. Ensure by contract that the ground goes first i.e. the space segment must
be compliant with the existing ground system not the other way around. Use new technology where there is a good
chance of an end to end cost reduction e.g. MO services.
Problem: Limited budget for payload operations
Solution: Use file based operations for as much of the experiment segment as possible. Experiments are treated
as software images to be uploaded and offline experiment data recovery and distribution is all done by files. Provide
hands-off remote operations for experiments based on simple interfaces. Provide a framework for the experiments
based on MO services (see chapter VIII). Perform automatic testing of experiments on identical hardware/software
to the spacecraft before loading it.
Problem: Limited budget for ground stations
Solution: Deploy a small antenna at ESOC for S/X/UHF operations and dedicate it to the mission.
Problem: Limited budget for ground facilities
Solution: Deploy the mission control system in a lab environment rather than the usual high performance control
facilities. Use the internet for ground station connections. Reuse infrastructure wherever it reduces the end to end
cost e.g. the mission control system talks to the satellite with exactly the same MO service packets even though the
transport route may be completely different e.g. UHF/Cubesat protocol link or CCSDS/S band link
Problem: Limited budget for non-core mission control software development e.g. mission planning, flight
dynamics, database management
Solution: Keep all these areas as simple as possible by requirement handling and design so that in house tools
based on office or open source software can do the job.
These solutions imply that the mission will try out completely new ways of working with experimenters. The
basic workflow is that they will provide the mission control team with on-board images that are already self-
consistent. These will be delivered to ESOC by SFTP and then automatically loaded on to the flatsat (a hardware
copy of the satellite laid out in a flat configuration). Then automatic tests will be run to check that the image meets a
few safety requirements while running. If it passes the image will be loaded to the spacecraft processor and booted
at a predefined time. Once running the experimenter will have several options on how to interact with his flying
software, either by a real-time packet interface over the internet or a higher level MO service application layer. Or
he can elect to simply interact via file transfer. Those experimenters that want to change ground software will have
various options on plugging into the ESA system at different access points.
The mission operations concept is therefore robust and at the same time low cost. The robustness of the satellite
will be exploited so we can allow experimenters to load their own complete images to the SEPP on a daily basis
without extensive checking by ESA. Experimenters will also be able to update the corresponding ground system.
This will allow them to change the end to end control chain from a CCSDS ground-space control interface to a TCP-
IP/web-based interface during a single ten minute pass. The concept relies on file exchange as the primary mode of
changing configurations. On the ground this will be done by allowing the experimenters to deploy their own virtual
machine at different access points in the ground control chain. To change the configuration on the spacecraft, the
experimenters will provide bootable memory images for the SEPP as input. These images will be tested on a flatsat
Downloaded by 191.101.64.122 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2354
American Institute of Aeronautics and Astronautics
9
at ESOC to check they meet the basic safety requirements and then uploaded to the spacecraft’s eMMC memory
card using a state of the art protocol called CCSDS File Delivery Protocol (CFDP). This same protocol will be used
to download experimenter’s data once it has been compressed into a single file on-board.
The experimenters will be given different interfaces with which they can access the ESA infrastructure to
monitor and control their experiment in real-time or offline, see chapter VII.
We also intend to allow the experimenters to exploit another innovation as part of the OPS-SAT mission. That is
the introduction of MO services which is the latest CCSDS standard in ground-space interaction for the
orchestration and housekeeping of satellites. In co-operation with the prime ESA is developing a complete set of on-
board services that will run on the SEPP and will provide the associated ground software to interface with them to
the experimenters. This is the so called Nanosat MO Framework, see chapter VIII. It will allow the majority of
experimenters to deploy their experiments in the form of simple “Apps” which can effectively control the satellite.
An OPS-SAT related study at ESOC has concluded that OPS-SAT could fly Mission Operations Services on-
board with minimal changes to our CCSDS/PUS compatible ground system, SCOS 2000. The advantage of this for
the on-board software developers will be the delivery of a machine readable interface (XML) for this ground
interface which will significantly reduce the development risk. OPS-SAT will be the first flight of Mission
Operations Services.
VII. Experimenter Access
One special aspect of OPS-SAT is that we allow the experimenters to communicate directly with their
experiment running on-board, even in real-time. From the experimental processor they can operate the camera, GPS
unit, fine ADCS (including reaction wheels, star tracker magnetorquers, magnetometers, sun sensors, gyros) and
they can also process data arriving from the software defined radio, GPS unit and core avionics.
We offer six different possibilities for the experimenters to access the OPS-SAT network and then communicate
with the satellite or the testing facilities:
1. They can exchange files via SFTP with a data relay server at ESOC which serves as the interface between the
OPS-SAT LAN and the internet. Files which contain the down-loaded telemetry of the experiments will be stored
there. In the other direction they can load their own software images which will then be uplinked to the experimental
processor by the flight control team.
2. They can use the Mission Operations Services standards to monitor and control experiments running on the
processing platform of the spacecraft. The raw MO messages are transferred between the user and the data relay
server using TCP/IP over the internet. These are then forwarded to the spacecraft and back automatically by the
OPS-SAT ground segment.
3. Experimenters that don’t want to write their own MO based M&C software can use Web-EUD for that
purpose. Web-EUD is accessible through a web browser and connects to the experiment through MO. It provides the
user with tools to monitor their experiment software and they also can send basic commands to their software.
4. They can use the Space Packet Protocol to monitor and control experiments running on the processing
platform of the spacecraft, also via TCP/IP over the internet. These are then forwarded to the spacecraft and back
automatically by the OPS-SAT ground segment.
5. For experimenters wanting to communicate with their experiments over a non CCSDS protocol then the
OPS-SAT ground segment will offer a direct connection at ground station baseband level i.e. just before modulation.
6. For experimenters that use CCSDS standards and are interested in real-time data but do not want to process it
themselves we offer a web based monitoring solution using an ESOC developed solution called WebMUST. The
experimenters can access advanced display, store and retrieval functions with a web
Downloaded by 191.101.64.122 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2354
American Institute of Aeronautics and Astronautics
11
Figure 5. OPS-SAT Ground Segment showing experimenter access
VIII. The Standard On-Board Image
As part of the space segment contract, industry must provide a so called “standard image”. This is defined as a
SEPP configuration that demonstrates that the OBSW deployed on this unit can communicate with and control all
the peripherals including the ground. Both ESA and industry decided to take this concept a little bit further in order
to ease the life of the majority of OPS-SAT experimenters.
Since 1994, ESA has used the
Packet Utilisation Standard (PUS) to
define how the mission control center
communicates with the corresponding
on-board software at application level.
The PUS consists of a set of services
and subservices which define the
messages that need to be exchanged
between the two entities in order to
request different services e.g. load a
command for later execution. PUS is
based on early 90s’s technology and
now the SM&C working group of the
CCSDS has defined a modern service-
oriented architecture for these services
instead. The goal is to define a set of
standardized, interoperable mission
operation services, which allow the
rapid and efficient construction of co-
operating space systems (Ground
Segment and Space Segment). The
working group has defined a layered
service framework, which allows
mission operation services to be
specified in an implementation and communication agnostic manner.
TU Graz in partnership with ESA decided to use this concept in the standard image. A CCSDS Mission
Operations On-Board Software Development Framework for Nanosatellites, called Nanosat MO Framework, is now
being developed and is intended to be implemented and used by OPS-SAT experimenters whose apps will
communicate with the ground and who will request on-board services e.g. switch camera on, using this protocol.
The main design characteristic of the NanoSat MO Framework software architecture is the creation of
independence between the application layer (apps) from the underlying platform. In order to create this
independence, a set of services shall be made available which can be used by the apps both for interfacing with the
peripherals and for communicating with the ground. These services will be based on the CCSDS Mission Operations
framework and can be divided in two main sets, the CCSDS MO Standardized services (STD services) and the
Peripheral services. In the set of the STD services, it shall provide two sets of standardized MO services: Common
Object Model (COM) services, Monitor and Control (M&C) services. In the set of the Peripheral services, it shall
provide: Camera service, ADCS service, GPS service, Software-defined Radio (SDR) service.
This abstraction should allow an easier and faster development of the experimenter software. The NanoSat MO
Framework will be freely available for download and it will provide a “ready to be used” implementation of all the
up-to-date CCSDS MO Standardized services and the defined Peripheral services.
The separation of the services from the specific experiment code not only allows an easier embedding of
standard CCSDS MO services with the different experiments but also avoids the need to keep track of the specific
CCSDS MO service requirements by the experimenter. The experimenter will be able to integrate these services in
their experiment even if these services are in reviewing phase. To get the latest version update, the experimenter will
only have to do a “pull request” from the server.
A development environment is intended to be provided to all OPS-SAT experimenters in order to facilitate the
development of experiments. In this development environment, experiment demos will show how to use the
NanoSat MO Framework correctly. A tutorial guide is also intended to be provided.
Downloaded by 191.101.64.122 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2354
American Institute of Aeronautics and Astronautics
12
IX. Experimenter Mission Operations concept
Each experimenter has an own user account on the Data Relay Server which serves as a connection between the
OPS-SAT network and the outer world. Using SFTP they can upload experiments to their user directories at any
time. There they are gathered automatically and moved to a central folder for acquired files. The experiment is then
tested using the FlatSat and either accepted or rejected by the Flight Control Team (FCT). Experimenters get
notified about the outcome so they can try it again with a new version in case of a rejection.
Accepted experiments are renamed according to the order in which they are going to be uplinked to the satellite
and moved to the uplink queue on the Mission Control System Prime and Backup Servers. During a pass
experiments are then uploaded to the satellite by the FCT using CFDP. If the upload is successful the experiment
can be activated by the FCT. Once an experiment is activated or finished the use is notified as well.
Although upload and activation has to be done by the FCT the experimenters can monitor and command their
applications themselves by sending telecommands or receiving telemetry through the Data Relay Server. Thereby a
SSH connection is used to establish the connection between the user and the server via two TCP/IP Sockets, one for
TC and one for TM. This TC/TM connection is limited automatically to the users which are having an active
experiment running on the satellite at that very moment.
How experimenters are controlling their experiments can be chosen by themselves. One option is to use MO
services or custom packets for real-time operation. An alternative would be to simply let their application run
independently and only receive downlinked data as files after it is finished.
Downloaded by 191.101.64.122 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2354
American Institute of Aeronautics and Astronautics
13
X. Conclusion
We conclude by pointing out that the operational concept for OPS-SAT has been quite challenging. Building a
system that can handle over one hundred experimenters all wanting to change the on-board software of a satellite
every day is bad enough. Doing it with very little budget is quite another thing. However with a mixture of good end
to end design, involving the experiment, ground and space segment, we have succeeded. This system will enable any
OPS-SAT experimenter to provide their on-board software (or firmware) as a file, deliver it over the internet and
have it automatically tested against the real satellite hardware/software, have it loaded and then activated on the
satellite at a particular time, be able to interact with it in real-time across the internet, use it to point the satellite, take
pictures or videos, process information from the GPS or Software Defined Radio, process those results, send the
results to the ground and have them delivered back to them across the internet.
What does ESA/ESOC ask in return for this service? No documentation, no payment, zero bureaucracy; only
that in some way the experiments help to evolve the technology we presently use to control and operate our
satellites. Please contact the author to become a registered OPS-SAT experimenter and secure your place in the
experiment execution timeline.
Figure 6. OPS-SAT Experimenter Mission Operations concept.
Downloaded by 191.101.64.122 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2354
American Institute of Aeronautics and Astronautics
14
References
1C. Coelho, D. Evans, O. Koudelka, “CCSDS Mission Operations Services on OPS-SAT”, 10th IAA Symposium on Small
Satellites for Earth Observation, 2015
2C. Coelho, M. Merri, M. Sarkarati, O. Koudelka, “NanoSat MO Framework: Achieving On-board Software Portability”,
SpaceOps, 2016
3CCSDS, Mission Operations Services Concept, Green Book. Issue 3. December 2010
4CCSDS, Mission Operations Reference Model, Magenta Book. Issue 1. July 2010
5C. R. Haddow, F. Flentge , F. Keck, M. Pecchioli and M. Schmidt, “File Based Operations - Architectures and the
EUCLID Example”, SpaceOps 2014
6D. Evans, Olivier Chattlain, Neus Monge Raluy, “The ESA POCKET Housekeeping Telemetry Compression: Ready to
Fly”, Spaceops 2016
Downloaded by 191.101.64.122 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2354
