OPS-SAT: Preparing for the Operations of ESA’s First NanoSat

Full text

American Institute of Aeronautics and Astronautics
1
OPS-SAT: Preparing for the Operations of ESA’s First
NanoSat
David Evans1, Alexander T. Lange2, José Luís Feiteirinha3, Jan Nörtemann4, César Coelho5
ESA/ESOC, Darmstadt, D-64293, Germany
This paper describes the unique mission design 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 design is unique in several ways not
least because the operation concept 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 design 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 this mission is already successfully pushing the boundaries at ESA and ESOC.
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 designed specifically to do just that. To our
understanding this is the first mission world-wide dedicated exclusively to advancing operational technology. The
mission now has over one hundred registered experiments from 17 Member States selected for flight.
When designing the mission we had a choice to make for the ground and space infrastructure which will allow
these experiments to fly: Be conservative and only reuse elements that have already flown or set an example and fly
innovative and new elements as part of that infrastructure. We chose the latter and so OPS-SAT will be the first
flight for Mission Operations Services (a potential replacement for the ESA Packet Utilisation Standard), CCSDS
1 Project Manager, Special Projects Division, ESA/ESOC, Darmstadt, Germany.
2 Project Assistant, Special Projects Division, ESA/ESOC, Darmstadt, Germany.
3 Data System Manager, Data Systems Division, ESA/ESOC, Darmstadt, Germany.
4 Software-Engineer, Data Systems Division, ESA/ESOC, Darmstadt, Germany.
5 PhD Researcher, Graz University of Technology, Graz, Austria.
O
Downloaded by 185.158.133.203 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2490
SpaceOps 2016 Conference
16-20 May 2016, Daejeon, Korea 10.2514/6.2016-2490
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
File Delivery Protocol (CFDP) and File based operations using MO Services. It will be the first ESA mission to
employ an extremely high uplink rate (256 kbps) and the first to use the ESA developed automation system MATIS
to achieve total automation. This paper will describe the challenges that these new developments create and how the
mission control team is tackling each one.
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.
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.
Downloaded by 185.158.133.203 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2490

American Institute of Aeronautics and Astronautics
3
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 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.
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
Figure 1. OPS-SAT front view.
Figure 2. OPS-SAT rear view.
Downloaded by 185.158.133.203 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2490

American Institute of Aeronautics and Astronautics
4
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.
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.
Downloaded by 185.158.133.203 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2490

American Institute of Aeronautics and Astronautics
5
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:
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
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 185.158.133.203 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2490

American Institute of Aeronautics and Astronautics
6
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.
V. Mission Operations Concept
The mission operations concept is robust and at the same time low cost. The idea is to exploit the robustness of
the satellite to allow experimenters to load their own complete or partial images to the SEPP on a daily basis without
extensive checking by ESA. Experimenters will also be able to plug in their own 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. To change the configuration on the spacecraft, the experimenters will provide bootable
memory images or FPGA configurations for the SEPP as input. These images will be tested on a flatsat at ESOC to
check if they meet the basic safety requirements and then uploaded to the spacecraft’s eMMC memory 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 uplink will take place at 256 kbps
to allow a reasonable turnaround time.
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.
To ease experimenter usage in addition to the option of providing bootable memory images or FPGA
configurations for the SEPP, ESA intends 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.. It will allow the majority of
experimenters to deploy their experiments in the form of simple “Apps” which can effectively control the satellite.
VI. High speed uplink
To give the experimenters as much freedom in their experiment designs as possible, they will have the
possibility to upload complete Linux images to the spacecraft. These images can become quite big and it might be
necessary to resubmit the images frequently. Because of the limited time available and the large amount of
registered experiments, we need a decent upload speed. It was decided that we will support an uplink speed of a
least 256 kbit/s, making OPS-SAT a mission with the fastest uplink speed in ESA’s history.
During the development of the MCS it was noticed, that SCOS 2000 in use with NIS and SLE-API is not able to
handle the desired uplink speed. Since we will have access to our own small antenna it was decided to not use the
Downloaded by 185.158.133.203 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2490

American Institute of Aeronautics and Astronautics
7
SLE for the upload of experiments. This approach reduces the amount of overhead a lot and we were able to show
that our solution can handle uplink rates of up to 1,000 kbit/s (without RF equipment, for the simulation LAN was
used).
To achieve this we decided to bypass SCOS and NIS and route the data units generated by CFDP directly to the
ground station via a TCP/IP connection. Due to the modular structure of SCOS, CFDP and NIS this was merely a
configuration change and there was no need to modify the source code any of those components. See also Fig. 3
which shows a comparison between the normal and the OPS-SAT configuration. Note that the CFDP
acknowledgments are still routed the normal way over SLE through NIS and SCOS.
I. Headings
VII. Remote Experiment Operations
One special aspect of OPS-SAT is that we have committed to allowing the experimenters to communicate
directly with their experiment running on-board, even in real-time. This means that they can effectively remotely
operate the on-board camera, GPS unit, fine ADCS (including reaction wheels, star tracker magnetorquers,
magnetometers, sun sensors, gyros). This is a completely new way of interacting with experimenters and has taken
considerable design effort to create a space and ground segment which allows this without compromising the
security and operational safety aspects of the mission.
The OPS-SAT mission offers 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.
Figure 3. Bypass of SCOS and NIS for uplinking. The left side shows how CFDP is configured normally, the
right side shows how it is used for OPS-SAT.
Downloaded by 185.158.133.203 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2490

American Institute of Aeronautics and Astronautics
8
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 browser.
VIII. File Based Operations
We released very early on in the mission design that using Files instead of packet based messaging for handling
the experimenter images and science data would be a major simplification for us. File Based Operations increase the
abilities, the flexibility and the overall usability of handling files compared to the limited abilities of traditional
packet based operations. With FBO there is a proper file system on the spacecraft and a HMI which looks just like a
FTP client. This gives the users the possibility to create, delete, rename and of course upload and download files
easily as if they would do those operations on a local computer.
In order to reduce operations costs, the mission has adopted a strictly file based operations model for transferring
large amounts of data to the spacecraft (OBSW images) and from the spacecraft (video, images, data files). The first
time that ESA will use this mode of operation on a traditional mission is Euclid. This mission is scheduled for
launch in 2020 and will explore dark energy and dark matter in order to understand the evolution of the Universe
since the Big Bang. It will generate about 100 GB of science data per day. ESOC ran a study investigating how to
deal with such a large amount of data using CCSDS CFDP as the underlying protocol. This study resulted in a
ground to ground prototype to prove the principle.
We realized early in the design phase that thanks to the powerful processing power of the experimental processor
we could run this ground software on-board the spacecraft. Tests using the target on-board hardware proved that this
was possible and OPS-SAT effectively reuses the study prototype, flying one of the ground nodes in space. The
operational experience gained in OPS-SAT will feed back into the EUCLID mission.
SCISYS UK was assigned with a study in 2013 to demonstrate the end-to-end feasibility of File Based
Operations. The prototype that was produced during that study is stable enough to fulfill the requirements for OPS-
SAT. Fig. 5 shows the FBO HMI. The left side of the HMI shows the files on the ground, while the right side shows
a model of the files on the spacecraft. The HMI allows to create, delete and rename files or folders. Also it allows to
initiate a upload or a download of a file, which are checked out or committed to the FARC respectively after the
transaction. The lower part of the window shows the verification state for each transaction. For the actual
transmission of files FBO utilizes CFDP.
The OPS-SAT development team has effectively managed to update the FBO prototype with a newer version of
SCOS and updated it to handle MO services, see later. This now forms the core of the OPS-SAT mission control
system.
Figure 4. OPS-SAT Ground Segment showing experimenter access.
Downloaded by 185.158.133.203 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2490

American Institute of Aeronautics and Astronautics
9
IX. CCSDS Mission Operations Services Standards
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. This has the advantage that the messages can be defined in a common
machine readable format and be parsed easily by the different parties. This eliminates one of the problems of the
PUS which was ambiguity in the interpretation leading to different implementations. OPS-SAT will be the first in-
orbit demonstration of a spacecraft with fully MO-based on-board software and ground implementations.
It will be used in two ways. Firstly the core on-board software and the modified ESA mission control system
implement MO services as their application level protocol. ESA has modified the latest version of its mission
control software (SCOS 2000) to allow this and GMV Poland are implementing the corresponding OBSW.
Secondly a CCSDS Mission Operations On-Board Software Framework for nanosatellites, called NanoSat MO
Framework, is being developed by TU Graz in partnership with ESA and it is intended to be implemented and used
by OPS-SAT experimenters who will communicate with their software experiment from ground in a simple
manner.. The NanoSat MO Framework provides a standard on-board software framework for nanosatellites based
on the CCSDS MO Framework, that facilitates not only the monitoring and control of the nanosatellite software
applications, but also the interaction with the platform peripherals. This is achieved by using the CCSDS Mission
Operations Monitor and Control services included in the MO service suite and by defining a set of new Platform
services which shall also follow the MO services framework architecture.
The traditional on-board software (OBSW) is seen as an almost immutable software which is developed for a
particular use where future updates would imply patching specific memory areas. Moreover, many times the OBSW
is written for embedded devices which will never be updated again. The NanoSat MO Framework intends to change
the current view on OBSW by turning it into simple “apps” that can be easily developed, tested, deployed and
updated at any time without causing any major problem to the spacecraft.
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.
Figure 5. File Based Operations. Left: The HMI for handling files; right: how FBO interacts with the MCS.
Downloaded by 185.158.133.203 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2490

American Institute of Aeronautics and Astronautics
10
X. Ground Segment Automation
OPS-SAT will use the ESA developed Mission AutomaTIon System (MATIS) for the first time throughout the
project cycle. MATIS supports the automated execution of control procedures defined according to a high level
version of the PLUTO standard. It is similar to a spoken language hence it is easily readable or changeable by
people without any programming knowledge as well. OPS-SAT procedures will be written directly in this language
and consist of a set of interlinked scripts. This will be used during ground test activities (e.g. AIV, automated
regression testing of control procedures) as well as during the routine mission phases.
An advantage of MATIS is that it accesses the services of the underlying monitoring and control systems
through a Services Management Framework (SMF) layer, thus ensuring independency of the procedures definition
and the actual implementation of the system activities. MATIS also supports a generic script and Java Messaging
Service (JMS) interface. This allows it to monitor and control the remainder of the ground system (antenna control
PC, file servers, mission planning, operational procedure tool).
The top layer of MATIS is a calendar which can contain an unlimited number of different schedules. These
schedules trigger procedures at specific times or in intervals. The procedures use predefined services for all actions,
e.g. sending telecommands via SCOS, executing scripts or managing files. These services utilize SMF drivers to
communicate with the different applications. MATIS procedures can have preconditions or watchdogs for
contingency cases.
The structure of MATIS consists of the MATIS server which interacts with SMF, the Operation Manager which
is contains the calendar and provides an interface for executing procedures to the user and the Designer in which
procedures can be created or changed. The Operation Manager and the Designer are using Subversion to control
changes in the procedures and schedules to allow having the whole set of elements version controlled and to provide
a multi-user environment.
The MATIS Designer provides an integrated short-loop edition environment with simple drag-and-drop and
autocomplete functionalities. It also has integrated consistency checks on all elements involved (Schedules,
Procedures, Ground Services, TM/TC data) to let the user know instantly if his changes are valid and are affecting
other elements or if there are other inconsistencies.
Although MATIS is a powerful tool which can be used to create all kinds of procedures the OPS-SAT mission
will be the first to try to implement it in an end to end way. Therefore it is planned to minimize potential risks by
creating elemental functions like sending a single command and verifying it or creating a parallel monitoring of a
telemetry parameter state. These functions can then be called by higher level procedures which together, for
example, automatically control a whole pass of the satellite.
XI. Conclusion
We have shown how a small and low-cost mission like OPS-SAT has succeeded in pushing the boundaries at
ESA/ESOC in the areas of high speed uplink, new space-ground protocols, automation and experimenter access. Its
mission is to enable a much faster evolution of operational technology which it will do thanks to the experiments
that will fly. However we can already state that, thanks to some brave choices by all the people contributing to the
project, this process is already well underway.
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
Downloaded by 185.158.133.203 on January 3, 2018 | http://arc.aiaa.org | DOI: 10.2514/6.2016-2490