1 Introduction

The space industry is one of today’s major growth markets and a very interesting business sector for innovation, science and technology. In the last century, space industry has dramatically changed and has undergone strong commercialisation, referred to as “New Space”. States started to cooperate with private companies and invested a larger amount of their budget into the commercial space sector. Even before the New Space era, the space industry was characterized by a strict standardisation approach to ensure the high reliability and quality of the space components. There is no doubt that high reliability and quality is crucial in order to save human life, to guarantee a long system lifetime and the mission success. Nevertheless, many New Space companies follow a different approach with other standards and processes to decrease development time and costs. Whenever possible, commercial general-purpose components, off the shelf (COTS), instead of the expensive space-grade components are used, because these components are typically produced by international companies in large quantities with comparable shorter lead-time and a lower price [1].

The success of many nanosatellite missions has shown that the use of commercial COTS hardware and software, in combination with screening and testing, yields very good results [2]. Such nanosatellites are often less expensive, but very powerful systems with the outstanding performance and functionality of state-of-the-art products. Consequently, the European Space Component Coordination (ESCC) [3] and the European Components Information Exchange System (ESCIES) [4] show an increasing interest in COTS.

In addition to the commercialisation, the concept of so-called CubeSats has become well established in the market in the last decade. The concept of CubeSats was first described by B. Twiggs and J. Puig-Suari in 1999 and later specified more precisely by the California Polytechnic State University as the CubeSat Standard [5]. CubeSats are small modular nanosatellites consisting of small 10 × 10 × 10 cm cubes. CubeSats are a very low-cost solution with adequate performance, enabling a particularly fast and economic development of satellites. Consequently, CubeSats are especially interesting for universities and companies that want to develop economic satellites in a relatively short time frame.

The European Space Agency (ESA) has acknowledged this trend and uses CubeSat nanosatellites for some missions. These missions include the OPS-SAT mission, where ESA is acting as the sole owner and operator of a CubeSat for the first time. The OPS-SAT mission has the goal to bring new technology and concepts into space to break the rule “has newer flown—will never fly” [6]. OPS-SAT aims to demonstrate in space new operational concepts like file-based operations, continuous software update concepts or the new Missions Operations (MO) services. Furthermore, the OPS-SAT nanosatellite is a flying laboratory in space that provides the necessary hardware and software for the demonstration of new space technologies. Different institutions and companies have expressed their interest to contribute to the success of the OPS-SAT mission, by demonstrating their innovations and concepts as experiments on the OPS-SAT nanosatellite.

The OPS-SAT satellite was successfully launched as part of the VS23 Soyuz launch on the 18th of December 2020 from Kourou space port in French Guyana. OPS-SAT was successfully brought to and deployment at its final 515 km LTAN 09:30 h orbit after a flight time of about four hours. Since then, the OPS-SAT satellite is successfully operated in space.

2 The use of embedded systems for the OPS-SAT satellite

Shown in Fig. 1, the OPS-SAT nanosatellite system architecture is organized into a CubeSat bus and a payload segment. The CubeSat bus segment contains all essential satellite core systems required for the operation of the satellite. Examples for these systems are the Main On-Board Computer (OBC) for the On-Board Data Handling (OBDH), Communication System (COM), Attitude Control System (ACS) and Electrical Power System (EPS). The CubeSat bus provides the necessary infrastructure for the rest of the satellite represented by the payload segment. The payload segment consists of an Experimental Attitude Determination and Control System (ADCS), X‑Band Transmitter, Optical Receiver (OPT-RX), HD camera, S‑Band Transceiver, CCSDS Protocol Engine, Software Defined Radio (SDR) Receiver and the Satellite Experimental Processing Platform (SEPP). All these payload devices represent the scientific and experimental part of the satellite, enabling the achievement of the scientific mission goals. The CCSDS Protocol Engine implements a CCSDS compliant data encoding and decoding for the CCSDS Missions Operations (MO) Services, which are used for the first time on an ESA satellite. The MO Services provide the core Telecommand (TC) and Telemetry (TM) interface running on the Main OBC and the SEPP, replacing the old Packet Utilization Standard (PUS). The S‑Band transceiver and X‑Band transmitter act as ground interface and physical layer for the MO Service based TC upload and TM download, allowing a TC data rate of 256 kbps and TM data rates of 1 to 50 Mbps. The S‑Band, X‑Band and CCSDS Engine are used for spacecraft operations but also allow the experimenters to implement their own communication standards and concepts during experiments. The SDR payload is an extension of the SEPP for experiments developed to receive RF radio signals between 300 and 1600 MHz. The Optical Receiver payload is designed for the reception of pulsed laser signals and can be used for optical experiments. For special experiments that require a specific satellite pointing, the ADCS payload system can be used. The ADCS payload allows implementation of standard pointing modes like Earth Target Pointing or the implementation of custom pointing algorithms from within the SEPP. And finally, a HD camera allows the capturing of images from Earth or Space.

Fig. 1
figure 1

OPS-SAT system architecture with CubeSat Bus and payload segment

Full size image

OPS-SAT uses a large number of CubeSat and Payload systems, but what is the common characteristic of these devices? The short answer to this question is that most of the CubeSat bus and payload systems have the typical architecture and characteristics of an embedded system. Embedded systems are often defined as processing systems embedded into larger enclosing products. In contrast to personal computers, embedded systems are often not directly visible to the user [7]. Embedded systems are also characterised by the fact that they are typically not intended to be a general-purpose computer [8]. Embedded systems are applied computer systems with a more limited hardware than personal computers and are designed to perform dedicated functions [9]. Embedded systems are widely used for many applications. Embedded systems are also characterised by their connection to the physical environment through sensors that collect information about the environment and actuators that control the environment [7]. Consequently, embedded systems are often linked to the concept of cyber-physical systems [10].

The comparison of the characteristics of the OPS-SAT CubeSat bus and payload devices gives rise to the conclusion that most of these devices are embedded systems, because they contain processing units designed for a special purpose and interact with the on-board systems and the physical space environment. The interaction with the physical environment can be very rudimentary in case of a simple component but also very complex in case of sophisticated scientific instruments. For example, the electrical power system interacts with the sun light and the solar panels that convert the sun light to electrical power. The generated electrical power is then used to charge some battery, converted to required voltages and distributed to other devices inside the satellite.

3 The Satellite Experimental Processing Platform (SEPP).

The heart of the OPS-SAT payload segment is the so-called Satellite Experimental Processing Platform (SEPP) Mainboard PCB. The SEPP Mainboard is a Linux OS based high-power processing platform based on the Intel Cyclone V System-on-Chip (SoC) component with an ARM A‑9 800 MHz dual-core CPU and a Cyclone V FPGA, a 1 GB DDR3 RAM, a 16 GB eMMC storage memory and other commercial electronic components that can be found in many laptop computers, tablets and smartphones. Fig. 2 shows the basic architecture of the SEPP Mainboard PCB [1].

Fig. 2
figure 2

Simplified block diagram of the SEPP Mainboard PCB Processing Unit [1]

Full size image

The SEPP Mainboard is designed to control and monitor all other payload systems and acts as platform for the execution of all OPS-SAT experiments. In other words, the SEPP represents the processing unit inside a virtual embedded system formed by the sum of all payload systems. The SEPP user data input and output are realized with Telecommand (TC) and Telemetry (TM) commands. The TC is generated on ground and transferred via the on-board communication systems to the processing unit. The processing unit receives the TC, executes all required processing steps and outputs the collected and generated data as TM. As well, the processing unit generates a lot of internal debug and status TM. Whenever required, the processing unit interacts with the payloads and space environment via the existing interfaces, sensors and actuators. The presence of sensors and actuators that form a “hardware in a loop” (HIL) is typical for embedded systems [7]. The sensors and actuators are located inside the various payload systems. Examples of sensors are magnetometers and gyroscopes for measuring the attitude and movement of the satellite. Examples for the actuators are the magnetorquers inside the attitude control system that allow active alignment of the satellite to the Earth magnetic field [1].

The use of SEPP allows the implementation of a user-friendly framework for the centralized experiment execution. This is very important, because it is hard for many of the experimenters to handle all the different payload devices with all their special functionalities and software interfaces. The SEPP abstracts the underlying complexity of the payload devices by providing a homogenized interface for all experiments in form of standard Linux OS device drivers and a software framework with libraries for the experimenters. This approach simplifies the implementation and execution of the experiments but also the operation of the satellite, because most of the ground TC have to be sent to the OBC and the SEPP only.

4 The SEPP as driver for mission success

As already mentioned, the OPS-SAT satellite was successfully launched as part of the VS23 Soyuz launch on the 18th of December 2020 from Kourou space port in French Guyana and is since then operated successfully in space.

The SEPP is a key to mission success, because it enabled the commissioning of the payload systems and the fulfilment of the primary mission goals. The SEPP demonstrates the possibilities of using commercial products in combination with mature design concepts, thus successfully breaking the undesirable “has never flown—will never fly” cycle [6].

Another very important achievement is the use of the CCSDS Missions Operations Services [11, 12] for the ground-to-space communication and control of the experiments [6]. As previously mentioned, the SEPP software is essential in order to control and monitor the OPS-SAT payload systems before and during experiments. For these purposes, the SEPP Linux OS is equipped with some special user-space application software. The File Management System (FMS) software provides a CCSDS File Delivery Protocol (CFDP) based file transfer functionality between the ground infrastructure and the SEPP. The CFDP file transfer was successfully executed and tested with large data files of more than 10 Mbyte for the first time in space. The FMS is very important in order to be able to use the S‑Band high-speed link for the upload of new Linux packages, applications or experiments to the SEPP and the download of any data to the ground. The so-called Nanosatellite MO Framework (NMF) is a software framework based on Apps that gives experimenters a user-friendly and easy way to execute their SEPP experiments and access some of the payload systems. The NMF abstracts access to the payload devices to allow easy integration of additional software Apps [13, 14]. The NMF uses the CCSDS based Mission Operations Service, instead of the very old but still used Packet Utilisation Standard [15], as the communication service between the ground and space segment. As well, the so-called Space Shell was successfully used in space for the first time. The Space Shell allows the execution of simple communication and configuration tests. Afterwards, more complex test experiments were implemented with the SEPP user-space C/C++ API Library on ground and uploaded to the SEPP with the CFDP based FMS software. The uploaded test experiments were successfully executed with the NMF. Consequently, many interesting experiments could be executed successfully with the various payloads.

The OPS-SAT HD Camera was powered on and tested successfully for the first time during the SEPP commissioning. The SEPP C/C++ API library and the NMF were used to implement a simple test experiment that configures the HD camera via the SEPP USB interface and captures a series of images with a pre-defined exposure time. Many of these SEPP tests had the goal to determine a feasible HD camera gain (ISO factor) and exposure time but were also used to implement some image processing and additional features like image compression and the generation of thumbnails. These commissioning tests and extensions were all implemented with the SEPP experiment infrastructure and yield to a very detailed understanding of the HD camera behaviour in space. After finding the correct HD camera settings, we could finally capture the first good HD camera shown in Fig. 3. The image was captured on 26th of July 2020 and shows the centre of Svalbard with its sea fjords and glaciers that flow into the sea.

Fig. 3
figure 3

One of the first good HD camera images from OPS-SAT showing Svalbard [ESA]

Full size image

As well, a first SEPP SDR receiver test experiment was executed with the goal of verifying the functionality of the complete SDR signal chain in orbit. The SDR signal chain consists of an UHF monopole antenna, the SDR hardware and the SEPP Mainboard. The SDR reception test was a great success because we were able to successfully perform UHF band spectral monitoring with the SDR and SEPP for the first time [1]. In the meantime, further experiments were executed. One example is the implementation of a GNU Radio based search and rescue receiver [16].

In the course of OPS-SAT commissioning, we discovered that the sun and the nadir pointing with the CubeSat bus ADCS was not working properly. The CubeSat bus ADCS is implemented with the Main OBC and is designed for a coarse attitude control with a pointing accuracy of about 10 degree, by using a magnetic sensor, acceleration sensor, Fine Sun Sensor (FSS), six photo diodes and three simple magnetorquer coils. A proper pointing is very important for charging the batteries and the communication over the S‑Band CCSDS link, because this requires the alignment of the satellite to the sun (sun pointing) or the Earth surface (nadir pointing). Hence, it was decided to commission the experimental ADCS payload system as soon as possible so that it can be used as a replacement for the CubeSat bus ADCS. The experimental ADCS should provide a much better pointing accuracy of less than 1 degree during the sun and nadir pointing. Unfortunately, the experimental ADCS is a very complex payload systems with a large set of command and telemetry parameters. It is to be noticed that the CubeSat bus Main-OBC uses only a very small subset of the ADCS payload system commands, because of its limited memory. Moreover, the OBC telemetry memories used at that time were only designed for rather short data sets. Consequently, the very time-consuming ADCS payload commissioning, the necessary procedures for the attitude control tests and the collection of the important telemetry were implemented and performed entirely with the SEPP.

By using the SEPP software framework, the detumbling and sun pointing modes could be successfully activated. In preparation for further ADCS tests, the experimental ADCS star tracker was first activated and an attempt was made to align it with the dark space by rotating the satellite step by step. After completion of the star tracker tests, further SEPP experiments were implemented for the target pointing modes Nadir and Fixed-Earth. In the Target Pointing Nadir mode, one side of the satellite is aligned with the Earth centre. During some target pointing tests, images were captured with the HD Camera with the goal to visually determine the satellite line-of-sight vector and provided a conclusion about the position and orientation of the satellite during the flight. Fig. 4 shows two examples of a successful nadir pointing experiment with the HD camera pointing about 45° in flight direction. The map pins show the satellite position (sc_position) and the centre of the HD Camera images with respect to the Earth’s surface (img_centre) at a given time. The red lines represent the line-of-sight vector from the satellite to the ground [1].

Fig. 4
figure 4

Relations between the ground track, satellite position, camera images and LOS vector of two good iADCS Target Pointing Nadir tests [1]

Full size image

Fig. 5 shows a good target pointing Earth-Fixed experiment with the Kourou launch site as the target. The target pointing was okay during target approach and fly-by and started to fail only in the last two minutes of the pass. Nevertheless, there were also many experiments that failed due to an incorrect pointing, which revealed some weaknesses of the experimental ADCS system. From all experiments and tests, we can observe a strong relation between the accuracy of the target pointing and the correctness of the initial attitude knowledge, that is generated by the star tracker. Consequently, the intended target pointing accuracy of less than 1 degree is sometimes but not always achievable. Hence, further improvements are under development to achieve a better overall performance of the star tracker and the experimental ADCS control algorithms. One example for such an improvement is the calculation of the sun vector with the Main OBC and provision of the sun vector data to the experimental ADCS, as an extra input for its control algorithm.

Fig. 5
figure 5

Relations between the ground track, satellite position, camera images and LOS vector of a good iADCS Target Pointing Earth-Fixed test [1]

Full size image

Thanks to the HD camera image data, precise information about the correctness of the determined orientation, initial rotation and orientation adjustment could be obtained [1].

5 Conclusion

From the point of view of the OPS-SAT mission, all experiments with the SEPP payload embedded system were extremely successful. The use of the SEPP enabled the various tests of the experimental ADCS actuators, sensors and the star tracker, and was essential for failure identification and the verification of the ADCSs performance. The communication to ground, the necessary procedures, as well as the storage of the telemetry could be successfully performed during all experiments. The successful use of the MO services for the execution and control of the experiments confirms the benefits of using embedded systems within a CubeSat nanosatellite system. The great performance, immense functionality and flexibility of the SEPP, as well as its ability to interact with the on-board payloads makes this system to a great success.