SONATE (SOlutus NAno satteliTE) CubeSat mission
The SONATE CubeSat mission of the University of Wuerzburg, Germany, is a technology demonstrator for highly autonomous payloads. The term "solutus" in the mission name is Latin standing for "unlimited, free, ... autonomous" mission objectives. One of SONATE's primary objectives is to verify the key elements of ASAP (Autonomous Sensor and Planning) system on-orbit.
The ASAP planning system is a highly autonomous system, which can react interactively and intelligently to certain events provided by sensor systems. The main source of those events is the ASAP imager but in general any sensor which supports the meta data format could inform the ASAP planning system about any external events. Considering all those events, the ASAP planning system can generate appropriate suggestions for further observations. In this process, the planning system interacts with the satellite's onboard computer and might generate a new command list if required. For instance, when a meteor was recognized in the image by the ASAP imager, the planning system analyses its own and the satellite's available resources and decides, whether to further track and record the footage of the meteor. If the decision is positive, the planning system generates a new command list with the necessary commands to the attitude control system to change the satellite's attitude. All of this happens without any intervention by a ground operator.
Figure 1: Typical mission scenario of SONATE: ASAP-L is observing and tracking events, like a passing meteor (image credit: University of Wuerzburg)
Sensor complement (ASAP, ADIA)
ASAP (Autonomous Sensor and Planning) system
The general benefits of the high degree of autonomy implemented by ASAP are twofold: Firstly, it allows new satellite applications where fast response to external events (e.g. meteor entry into Earth's atmosphere for an Earth observation mission) is required. Secondly, it reduces the overall mission costs by moving workload from the operator to the satellite itself. To complete the verification of ASAP in a closed loop manner, ASAP needs to take over control of the satellite by manipulating SONATE's active command list. 1) 2)
However, the demonstration of the highly autonomous functions shall not put extra risk on the SONATE mission as a whole and especially the satellite's other payloads. In order to combine the high degree of autonomy required for the verification of ASAP with the common requirements of a technology demonstrator mission accommodating also other payloads, special measures must be taken. Those measures affect the verification process of ASAP itself, the OBDH (Onboard Data Handling) system, and the mission operations of SONATE. They include different check-out levels for the autonomous functionalities of ASAP, protective measures of the OBDH against unauthorized attempts of ASAP to control the satellite, new concepts for the mission planning process on ground, and directives for the mission operations on ground. The different check-out levels range from LEOP procedures common for every payload, through experiments during which ASAP runs but the plans are not executed, to finally full autonomous control of SONATE through ASAP. The protection of the OBDH is implemented by dedicated states in which the OBDH accepts commands from ASAP as well as a whitelist of commands to be accepted. Both for the mission planning process and mission operations on ground, new concepts had to be developed for this transition from classical operations towards full autonomy.
ASAP is an optical instrument, developed at the University of Wuerzburg. The main functionality of ASAP is twofold: Firstly, it consists of an ASS (Autonomous Sensor System ) used to detect and classify non-deterministic, transient events. Secondly, it integrates an APS (Autonomous Planning System). This implements the autonomy features needed to overcome the drawbacks of the conventional approach outlined in the introduction. The ASAP software runs on top of RODOS (Realtime Onboard Dependable Operating System), which also manages the communication with the OBDH via RODOS Topics.
The original design of ASAP consists of two optical sensors: A wide field of view sensor with a high data throughput and a near field of view sensor with higher pixel density and adjustable focal length. Having both sensors is justified by their different tasks. The wide field of view sensor detects and classifies events, whereas the near field of view sensor would be used to further track and observe the recently detected events.
However, the spatial dimensions of the SONATE nanosatellite do not allow the integration of both optical sensors. Therefore, the reduced configuration ASAP-L (light), will be integrated into the SONATE nanosatellite, containing only the wide field of view sensor. Apart from a reduced payload data quality, this configuration still allows all proposed reference scenarios. 3)
Compared to other nanosatellite missions ASAP collects quite large amounts of payload data, i.e. high-resolution image data, in the order of 100 MB/day, which affects the design of the payload data handling system as well as the communication system. The original system, shown in Figure 2 has a total mass of about 3 kg and a size of 175 x 245 x 100 mm3 and hence cannot be accommodated on a 3U CubeSat. Therefore, a reduced version named ASAP-Light (ASAP-L) of Figure 2, which features all key elements but a smaller and less powerful imaging system, was developed. 4)
ASS (Autonomous Sensor System): The ASS supports two modes of operations: Manual and Autonomous Mode, whereas the latter uses image-sequences to detect unforeseen events. The outputs of the ASS thus are image data as well as the results of the classification algorithm, which will be called meta-data in the following. This includes the type of the recently detected objects, the type of occurrence (new event, re-entrance) and the time of detection. Besides archiving it for scientific purposes, the meta-data is mainly interpreted by the APS to react reasonably to events.
APS (Autonomous Planning System): The APS is a platform independent software architecture developed within the ASAP project. Integrated into ASAP, it provides features to enable higher autonomy for the satellite, while staying highly configurable, as will be shown in the elaboration of the actual autonomous planning concept (Figure 3).
The APS follows a three-stage process: Decide, Schedule and Execute. In fact, all three stages are implemented as separate RODOS threads and thus work independently of each other communicating through shared data structures. This paper will focus on the Execution, since this stage is responsible for the synchronization of commands with the OBC. The other two stages are briefly outlined for increased comprehensibility. The interested reader may refer to 5) for more details.
Decide: The purpose of this stage is to decide which activities shall be considered by the scheduler. An activity is defined as a set of actions. Each action in turn is associated with a set of commands. Following this definition, ‘action' means starting, pausing, continuing or stopping the activity. ‘Recharge the battery' would be a common example for an activity allowing all of the mentioned actions. Several constraints can be assigned to a specific activity. An execution time frame in which the activity can be executed, could be such a constraint. Additionally, so-called resource utilization functions must be given. They define the impact of each activity on the satellites resources (i.e. the charging level of the batteries).
The decider processes two kinds of input information: Firstly, it receives new events in the form of meta-data, generated by the ASS or other subsystems. Secondly, it receives the housekeeping data from other subsystems to retrieve the satellite state. This includes in particular the power subsystem and the ADCS (Attitude Determination and Control Subsystem).
The decider is highly configurable: One must provide the information on how to interpret the input data, as well as the possible activities with their associated commands and resource utilization through configuration data. Given the input and configuration data, the deciding stage applies several strategies to select possible activities. The basic strategy is rule-based, whereby the actual rules have to be provided via the configuration process. This strategy is easy to comprehend, but it only allows minor autonomy in its decisions. Other strategies work goal-based or use neural networks, which would have to be trained with experiment data before.
Schedule: The scheduler has the task to calculate a conflict-free order of the time-wise-ordered actions associated with the considered activities. A plan is called conflict-free, if the resources stay within their given boundaries over time and all time constraints are obeyed. Additionally, a runtime-score and a finish-score can be assigned to each activity. These scores determine the weights influencing the scheduling. Finding the optimal time-order of the actions, i.e. maximizing the sum of scores per activity, is solved by using a branch-and-bound method. Once a time-order is proposed, all constraints can be translated into linear inequalities. This is possible because of the restriction of the resource profile functions to be a combination of step and/or linear functions. The resulting set of linear inequalities forms a linear program which can finally be solved using the simplex algorithm.
This is also advantageous regarding the solution of slightly modified problems, i.e. when the time order of two actions are interchanged, which could already be shown in simulations. The optimal solution of such a modified problem can be found much faster by the simplex algorithm when the calculation is based on the solution of the original unmodified problem. Nevertheless, finding an optimal plan is a computationally intensive task. Because of that reason, the scheduler provides the possibility to bypass the optimization and implement activities heuristically. Although this may create a conflicting plan at long term, it is no major problem as the scheduler regularly checks the actual state of the satellite resources and repairs its plans iteratively. An iterative reevaluation and optimization is conducted also for optimized plans, since the calculated resource trends do not necessarily hold true during the execution.
Execute: The executor is responsible for generating the commands associated with the actions of the scheduled plan. Since the plan will be updated in a non-deterministic way by the scheduler, the executor has to regularly update its internal list of commands. The command list supports to append elements and to clear the list as well as to insert and delete elements at an arbitrary position. Those operations are only allowed if all affected time-tagged and immediate commands are scheduled beyond a configurable synchronization and execution horizon. This list generally must be synchronized with the OBC depending on the check-out level of the APS . The synchronizations are carried out via RODOS topics. However, SONATE's OBC does not support the arbitrary insertion and deletion of commands. Instead, it implements specific commands to clear the ASAP command list on the OBC or append elements to it. Depending on its acceptance level of ASAP commands, the OBC may provide feedback, so called notifications, on the execution or rejection of commands or synchronization errors.
The problem of autonomous planning in principal has already been solved by other frameworks like ASPEN/CASPEN before. However, the APS is designed to be a highly configurable autonomous planning system which can be integrated into nanosatellites. The applicability for nanosatellites is possible thanks to the feature to bypass the computationally intensive optimization of plans. The configurability and modularity of the APS allows to adapt it basically for any mission independently from the design of the OBC and its software and to run the APS as an application of the OBC or on dedicated hardware. The configurability manifests in the possibility to add or choose between different strategies to decide on the mission-depended definition of activities, as well as the configurability of activities and resources including their complex relationships.
ASAP-Light consists of two major subsystems, the autonomous sensor (camera) and the autonomous planning system (Ref. 4). Those two components shall be described in more detail in the following sub-chapters. Both autonomous systems are running on a common hardware platform.
The hardware platform (mainboard of ASAP-L) shown in Figure 2 (right) is equipped with 1.5 GByte of DDR3-RAM for volatile storage and 32 GByte of FLASH for non-volatile storage of data. The board computer can choose between three different redundant (2 x) busses (UART, I2C, CAN) for communication (commands and telemetry). Payload data (image sequences) are provided by extra LVDS-based interfaces. Main parts of the ASAP-L processing logic, like image sensor control or processor, are implemented as intellectual properties (IP) on a field programmable gate array (FPGA).
Other parts of the ASAP-L processing logic (e.g. operating system, middleware and applications) are implemented as software which runs on a processor. The autonomous sensor (camera system) of ASAP-L is realized as both types – IP and software – and is therefore bound to the ASAP-L specific hardware platform. The autonomous planning system, in contrast, is implemented only as pure software and may because of that be put on to other hardware platforms like the OBC. This feature gives flexibility to other satellite missions where only autonomous planning functionality is requested and the autonomous sensor system can be omitted.
Autonomous Sensor System: As stated before the camera system is responsible for the detection of short, illuminous objects and events like lightenings or fireballs. 6) To accomplish this task, ASAP-Light has been designed to process 100 images/s with a resolution of 4 Mpixels in realtime. Figure 4 shows the data flow and the involved processes. A high-performance algorithm searches and filters the vast amount of data and tries to detect the mentioned events and phenomena. In case of a hit, sequences of images can be recorded in non-volatile memory and be downloaded on the following communication passes with the ground station. For larger amounts of data where several communication passes are required the data may be stored in the meantime in non-volatile flash memory. This would allow ASAP-Light to be shut down between passes without losing any data and saving energy.
In addition, the algorithm extracts describing information of the detection, called meta data, from the raw data input. Such information is pixel based and related to the image sensor, for example velocity, size, colour, brightness, etc. Additional higher computations which are implemented inside a software application running on the processor are required to map the detection to a reference object and to gain higher value information like position and velocity vector in relation to a 3-dimensional reference system, e.g. ECEF (Earth Centered Earth Fixed). This higher value information is necessary for the following autonomous planning system.
APS (Autonomous Planning System): The main purpose of the APS is to autonomously generate commands for the board computer of the satellite. This would allow the satellite to quickly react to external events because no responses by mission operator is required. The autonomous planning system consists of several internal components which interact together to provide the OBC of the satellite with the required autonomous functionality services.
The most important components and their data flows are depicted in Figure 5:
- Central (not shown)
- Data Manager (not shown)
- Event Manager (not shown)
One of the most important tasks of the APS is to maintain a valid plan which describes the currently running and future processes/procedure for the satel-lite. The plan must include the following information:
The above-mentioned components and data structures compose together the core of the autonomous planning system. To realize an autonomous satellite mission additional data must be provided by services.
ADIA (Autonomous Diagnostic system)
The ADIA system is an autonomous, model-based diagnostic system for nanosatellites. In the context of the ADIA++ project, funded by the German Federal Ministry for Economic Affairs / German Space Agency DLR (FKZ 50RM1524), a diagnostic engine in form of desktop software has been developed. 7)
The diagnostic engine takes measured sensor, command and housekeeping data as an input to simu-late a model of the satellite and thereby computes the expected state of the system. This simulated state is compared to the observed system state. Every threshold breach of a measured value and every discrepancy between a simulated and a measured value at any port of any component is called a symptom. Figure 6 illustrates this diagnostic process. The model is described by port-wise connected components with arbitrary many input and output ports with a quantitative description of their nominal behavior. Since the classical model-based approach limits the diagnostic capabilities to only being able to detect faults on component level, heuristic knowledge is used to enhance the quality of the computable diagnoses. This heuristic knowledge consists of error functions for components (e.g. if voltage and current are sufficiently high but the lightbulb is not emitting light, then the lightbulb is broken), majority decisions (e.g. compare the output of 3 identical sensors) and trend knowledge (e.g. extrapolate a certain parameter into the future). Trend knowledge is also used to compute possible future threshold breaches and therefore to detect future errors.
A version adapted the available resources of the SONATE mission, ADIA-L, is currently under development. In the context of the ADIA-Light project, funded by the German Federal Ministry for Economic Affairs / German Space Agency DLR (FKZ 50RM1723), an embedded version of the ADIA++ desktop software on an embedded platform is being developed. 8) ADIA-L's diagnostic routine will be executed as an application on the TI-RTOS (Texas Instruments -Real-Time Operating System) running on a BeagleCore, an industrial embedded computing module derived from the popular Beagle-Bone Black platform. It features an ARM Cortex-A8 AM335x processor by Texas Instruments (clocked at 1 GHz), 512 MB of DDR3 working memory, 4 GB of nonvolatile flash memory, and features various interfaces such as UART for communication with SONATE's OBDH. For redundancy, two BeagleCore modules will be integrated into SONATE, running in cold redundancy mode.
The ADIA-L payload poses several requirements onto the SONATE satellite bus. For one, ADIA-L requires the knowledge of all the satellite's housekeeping parameters. Therefore, these have to be provided to ADIA-L by the bus. Since the SONATE mission shall demonstrate the ADIA-L system in-orbit, measures are necessary to verify its functionalities. As the purpose of ADIA-L is to diagnose causes of failures, a test of the system requires the presence of anomalies in the SONATE housekeeping data. Obviously, a failure of a SONATE subsystem is not desirable. Therefore, measures have to be taken to fake the housekeeping data for the ADIA-L payload. Here, two options are available. Because the housekeeping parameters have to be provided by the satellite bus to ADIA-L, the bus can manipulate certain housekeeping parameters to simulate a failure for testing. As a second option, ADIA-L's model describing the satellite will contain certain nominal states of the satellite purposely defined as non-nominal.
Overview of the SONATE mission
The SONATE satellite is designed according to 3U CubeSat standards. It can be divided into two sections: the payload section in the front and the satellite bus section in the remaining space behind that. The payload section includes the ASAP-Light system, the star sensors and the three reactions wheels. It also accommodates two redundant HiSPiCO S-band payload data transmitters and the ferrite core coils for attitude control around the X-axis of the satellite, as well as the rolled-up UHF and VHF antennas. The remaining satellite bus components as well as the ADIA-Light payload are mounted on PCBs cards that are plugged into a backplane. This reduces the amount of cables to a number of cables between the payload interface board at the end of the backplane and the payloads in the payload section of the satellite as well as the HF cables between transceivers and antennas. Most other electrical signals are routed over board-to-board connectors without any cables (Ref. 2). The structure of the satellite and the accommodation of those systems inside the satellite are shown in Figure 7. Figure 8 gives an overview over all systems of the SONATE space segment and their interconnections. The 3U CubeSat has a mass of ~ 4.2 kg.
OBDH (OnBoard Data Handling): The OBDH represents the central data processing and handling unit ensuring a higher autonomy as well as commanding and monitoring all subsystems of SONATE. Its main tasks are the processing of telecommands and telemetry, the time management, the navigation based on the SGP4 (Simplified General Perturbations Model Nr. 4), the management for concepts of redundancy, the allocation of interfaces to all subsystems onboard SONATE and finally, the monitoring of its state with an autonomous response in case of failures or critical values, e.g. a low charge state of the batteries. All the mentioned tasks are performed on a dedicated hardware, the onboard computer (OBC). To process larger amounts of payload data especially originating from ASAP-L, additional hardware, the PDH (Payload Data Handling) system is used. Both OBC and PDH form the OBDH. Although executing different tasks both the hardware and software design of the OBC and the PDH are exactly the same. Thus, only by a decision of a software algorithm the tasks of the OBC and PDH, the so-called role, are assigned to a specific OBDH-board. In case of malfunctions, the roles can additionally be reassigned throughout the mission without resetting the OBDH-boards. The shared hardware and software design of the OBC and PDH thus decrease the development effort and increase the level of redundancy.
The hardware design is based on the powerful but resource efficient STM32F4 microcontroller unit to allow a fast processing of the required tasks, as shown in Figure 10. The software design is based on the real time operating system RODOS to communicate with the payloads via special gateways. Another advantage of implementing RODOS is the reduced development effort, as it already features multitasking capabilities as well as hardware abstraction layers for many standard hardware interfaces, and as the modular design of RODOS simplifies the development and implementation process of the different and independent tasks to be executed by the OBDH. Besides the management of interchangeable software roles between the OBC and PDH, SONATE carries two more OBDH-boards for reasons of redundancy. Those boards are in sleep or standby mode most of the time to reduce the power consumption, but stay synchronized with the running component and thus can basically be regarded as hot redundant.
Figure 9: OBDH hardware block diagram (image credit: University of Wuerzburg)
To meet the special requirements of the primary payloads the OBDH software features some uncommon applications which are executed by the OBC. While it is common, that the OBC collects different housekeeping data from all subsystems and condition it for the downlink, SONATE's OBC also provides all subscribing subsystems locally on board of the satellite with this set of data immediately after collection. This is facilitated by the subscriber-publisher paradigm implemented by RODOS and is mainly used by ASAP-L and ADIA-L. Furthermore, the OBDH-software implements a so-called man-in-the-middle application which subscribes this set of house-keeping data and can manipulate it before it further passes it to ADIA-L. With this mechanism one can inject particular symptoms of malfunctions into the housekeeping data to verify ADIA-L's diagnosis algorithms. While those two applications are uncommon but straightforward, the required command interface which allows ASAP-L to manipulate the original operational schedule is much more dedicated. SONATE's telecommand management stands out due to a complete second path of command processing for commands originating from ASAP-L as it is shown in Figure 10. This al-lows to basically process ASAP-L commands according to the same algorithms as standard telecommands.
Nevertheless, ASAP-L commands stay separated from the standard commands from the ground controller to implement protective measures against disallowed commanding through ASAP-L. Different levels of autonomous operations control to what extend ASAP-L commands are actually processed. In the lowest level of autonomy, i.e. classical operations, the ASAP-command interpreter does not accept any commands. Only at the highest level of autonomy, i.e. full autonomous operations, ASAP-L commands are accepted, inserted into the appropriate command list and finally executed at their due date. Intermediate levels which abort the processing of ASAP-L commands at specific check-out points allow to demonstrate correct functionality up to this certain point before advancing to the next higher level of autonomy. Another protective measure of the OBDH-software against disallowed commanding through ASAP-L is a whitelist mechanism. Disregarding the level of autonomy the OBC only accepts a well-defined subset of all commands from ASAP-L supported by SONATE. Especially critical commands, like switching of systems of the satellite bus or controlling the levels of autonomy, are excluded from this subset.
Power: The main objective of the electrical power subsystem design is to create a reliable and redundant system. Another special feature is that the EPS has to provide a relatively high output power of 20 W for simultaneous operation of the autonomous payload and the communication components. The electrical energy is generated by four electrically identical solar panels with six GaAs solar cells each. The conditioning of the solar voltage takes place in the components on the back-side of the solar panels, so that a regulated constant voltage can be further distributed. Two solar panels are interconnected and operate with two redundant solar bus systems, as shown in Figure 11. There are two redundant energy storage boards in the SONATE satellite. Each board contains four industrial Li-Ion cells with a total capacity of 12.8 Ah. A CC/CV charge controller is responsible for a safe charging of the batteries. All redundant satellite components are connected to one of two separate +5 V power busses. A power-up converter generates this voltage directly from the battery pack. Overall the EPS is specified as shown in Table 1.
Communication: For the communication between space segment and ground segment, SONATE will use amateur radio frequencies in the UHF band for the transmission of housekeeping telemetry to and telecommands from mission control with a data rate of 9.6 kbit/s. Therefore, the satellite bus includes two redundant AstroDev Lithium transceivers operating in hot redundancy, i.e. both transceivers are always receiving while only one transmits when required. A frequency of 435.025 MHz has been coordinated by the IARU (International Amateur Radio Union) for SONATE's UHF up- and downlink. The SSTV (Slow Scan TV) device will operate in the VHF amateur radio band. Here, a frequency of 145.840 has been coordinated. For each of both bands, two monopole antennas will be deployed at one end of the satellite, as shown in Figure 12. These antennas are made of steel tape which is rolled up inside the satellite during launch. After deployment a motor will set the tape free and allow it to unroll outside of the satellite.
Since the optical sensor of the ASAP-L payload can generate large amounts of data, a high-speed payload data downlink is required, too. Hence, two redundant HiSPiCO S-band transmitters are integrated into SONATE together with one patch antenna mounted on the satellite's side panels each. This allows up to 1.65 Mbit/s downlink in the non-amateur, space operation/space research service in S-band between 2261 and 2271 MHz.
Figure 12: UHF and VHF antennas in deployed state and one of the S-band antennas (in orange). The second S-band antenna is exactly on the opposite site of the satellite (image credit: University of Wuerzburg)
ADCS (Attitude Determination and Control Subsystem): To fulfill mission requirements, SONATE is equipped with an active ADCS. This is not only necessary for sun pointing and therefore to generate enough electrical energy for the power consuming autonomous systems, but also because the ASAP-L payload requires that its camera is pointed towards the Earth's horizon. At the same time, the S-band downlink, which is able to transmit the large amounts of payload data that are generated by ASAP-L, requires to point the satellite's antenna to the ground station with at least nadir-pointing accuracy.
To achieve this, SONATE is equipped with 6 magnetic coils, two in each axis for redundancy purposes. For the Y- and Z-axes (axes perpendicular to the satellites larger sides) air coils are used directly under the solar panels, whereas in the X-axis (along the longest axis of the satellite) ferrite core coils are used, in order to use the limited space inside the 3U CubeSat as efficiently as possible. The coils are electrically commanded by the Electrical Power Subsystem (EPS), which communicates with the ADCS mainboard via the satellite bus. As soon as the reaction wheels have successfully been tested in-orbit, they can be integrated into the control loop to counteract the drawbacks of an under-actuated control based solely on magnetic actuators. The latter will then be used for damping and desaturation purposes of the reaction wheels.
To precisely determine the attitude of SONATE, several different sensors will be used. A set of redundant MEMS gyros is being used for measuring the satellite's rotational movement around each axis. Both flux gate and magneto-resistive magnetometers are used to measure the local magnetic field vector, which in combination with an on board computed geomagnetic reference vector (IGRF) can be used for absolute attitude determination. In order to meet pointing requirements, two redundant sun sensors on each side of SONATE complete the nominal sensor set. These sun sensors are being developed in-house with regard to meeting accuracy and size requirements of the SONATE mission, a reference sun vector is being calculated via approximated analytical models. To allow a high degree of redundancy in case of sensor failures, SONATE is equipped on each axis with at least two redundant instances of each sensor. To increase the absolute accuracy of the attitude determination, the output of the star sensors of the AROS research project can be fused into the attitude determination result, as soon as its experiments have successfully verified its operation in orbit.
One ADCS mainboard holds two cold redundant units of identical standalone ADCS processing units for redundancy purposes. The main software runs on a STM32 L4 microprocessor and implements attitude determination and control algorithms, as well as communication protocols with connected sensors and the satellite bus for telemetry/telecommand purposes (Figure 13).
Secondary sensor complement
There are three secondary payloads on the SONATE satellite: a star sensor, a reaction wheel and an amateur radio payload.
Attitude control is an important part of most satellite busses. The control of the satellite's orientation does not only allow targeted Earth observations or astronomical remote sensing missions, but is essential for basic functions of the satellite bus. Among the existing attitude determination sensors, star sensors are usually the most exact ones. However, most existing star sensors are unsuitable for nano and pico satellites due to their size, mass and power consumption. Therefore, systems for the optimization of star sensors are an active field of research at the University of Würzburg. In the AROS (Advanced Researches On Star sensors technologies) research project, funded by the German Federal Ministry of Economic Affairs and Energy, represented by the German Space Agency DLR (FKZ 50RM1522), a software tool is being developed to optimize the design process of star sensors for pico- and nanosatellites.9) As a result of the optimization algorithm and to verify the output two sensors will actually be built. One of those sensors, OP1(Optimization Process Nr 1), with a size of 21 x 41 x 55 mm3 and a mass of 50 g, is optimized for the use on picosatellites. The space available in the SONATE satellite allows the integration of two OP1 sensors. If those sensors show good results during testing phase in orbit, they can be coupled with the attitude determination and control system of the SONATE satellite bus.
Figure 14: Left: CAD model of the OP1 star sensor, Right: CAD model of the reaction wheel (image credit: University of Wuerzburg)
To allow fast and precise changes in the satellite's attitude without the use of propellant, usually reaction wheels are used. In the context of student theses, a reaction wheel has been developed at the University of Würzburg and was adapted to the SONATE satellite, with a size of 32 x 32 x 24 mm3 and a mass of 51 g. The SONATE structure can accommodate three of these reaction wheels, one per each major axis. Like the star sensors, if those reaction wheels show good results during testing phase in orbit, they can be coupled with the attitude determination and control system of the SONATE satellite bus.
Also with contributions from student theses, the amateur radio payload of the SONATE satellite is being developed. It consists of a VHF transceiver which will serve in the SONATE mission as an SSTV (Slow Scan TV) transmitter. Using the images taken by the image sensors of the ASAP-L or star sensor payloads, this payload allows the transmission of low resolution images from the satellite to the ground, which can be received by radio amateurs world-wide using simple means and equipment.
Figure 15: Photo of the SSTV transceiver board (without HF shielding), image credit: University of Wuerzburg)
Figure 16: Image of the SONATE student development team,with Prof. Hakan Kayal (fourth from left), Prof. Alfred Forchel (President of the University of Würzburg, center of image) and project manager Oleksii Balagurin (fifth from right), image credit: Kristian Lozina / University of Würzburg)
Launch: The SONATE nanosatellite was launched as a secondary payload (along with other 32 secondary payloads) on 5 July 2019 (05:41:46 UTC) on a Soyuz-2-1b/Fregat rocket from Russia's far-eastern spaceport Vostochny Cosmodrome. The primary payload on this flight was the Meteor -M2-2 weather and climate-monitoring satellite of Roskosmos. The SONATE mission is designed to be operated for at least one year. 10) 11)
Orbit: Sun-synchronous orbit, altitude of 530 km, inclination = 97.7º.
Under the launch service contracts between the German company Exolaunch GmbH of Berlin and the Russian company JSC Glavkosmos, 28 satellites are being launched in the interests of Germany, France, USA, Israel, United Kingdom, Sweden, Finland, Thailand, Ecuador, Czech Republic and Estonia. 12)
All CubeSats on this launch are integrated into 12U and 16U EXOpod CubeSat deployers provided by Exolaunch. EXOpods were already successfully flown on multiple missions and deployed dozens of CubeSats. The deployment process and sequence of cubesats will be controlled by Exolaunch's electrical management unit EXObox to ensure safe and timely deployment. 13)
Table 2: Summary of payloads aboard the Soyuz launch on July 5, 2019
Risks of Autonomous Control Through ASAP
The benefits of the autonomous control of ASAP by emulating an operator on board have been outlined in the beginning and are thoroughly discussed in previous publications (cf. [ 14), 15), 16)]). However, it imposes several risks onto the mission, which may cause a loss of the mission in the worst case. We identify the following risks and their corresponding classification:
Invalid Plan: Due to malfunctions of the scheduling algorithm or imperfections of the model, especially of the resources, ASAP generates invalid plans causing resource violations or other conflicts.
Harmful Plan: ASAP generates a valid plan which contains dangerous or even harmful activities. On-orbit software updates of specific subsystems or changing the con-figuration of specific subsystems (e.g. calibration parameters of the ADCS) could be such activities.
Invalid Command List: This is the case if ASAP generates a valid and safe plan, but the following step of the translation into a command list results in syntactically correct but semantically invalid commands. Commands with undefined command code, wrong routing information, or invalid parameters are examples for such invalid commands. This error can be caused by malfunctions of the translation algorithms or erroneous definition of the commands in the ASAP configuration.
Synchronization Failure: This risk is associated with the very last step of the autonomous control, the synchronization of the generated command list with the OBC. It is caused by disrupted communication between ASAP and the OBC. This can lead to resource violations of essential resources although ASAP generated a valid plan and a correct command list. This would for instance be the case if the command to switch off an instrument were lost on the communication line between ASAP and the OBC, which in turn could cause a negative power budget.
Those risks are in fact not unique for autonomous control through an emulated operator, but classical operations face them as well. However, in the process of classical operations well-tested and dedicated methods of command validation on ground and matching methods of command verification on board are applied to minimize the risk. And ultimately the human operator can be asked or even supposed to rethink and double check the generated command list at least in questionable or critical cases.
Those methods of validation and verification are per se not necessarily implemented by the emulated operator as well and a human controlling instance of the "black box" ASAP is not available during full autonomous operations.
To nevertheless mitigate the risks, we have developed several concepts both for ASAP and the OBC which are discussed in detail in the following section. Their discussion reveals that they prepare the mission for the successful demonstration of the correct operations of ASAP and to meet also SONATE's other mission objectives.
Measures to Mitigate the Risks
To lighten the risks of autonomous Control through ASAP, the OBC provides different acceptance levels of ASAP commands. These levels serve as safety measures to protect the satellite. Additionally, ASAP implements check-out levels corresponding to the acceptance levels of the OBC. The reason to have both measures is due to their different purposes: The acceptance levels mostly provide safety to the satellite, whereas the check-out levels of ASAP are used to evaluate the functionality and to stepwise face the risks elaborated in the previous section. Depending on the check-out level of ASAP, the corresponding acceptance level must to be chosen to be as restrictive as possible, but still allowing the evaluation of ASAP. Further measures are taken also during the phases of full autonomous control to mitigate the remaining risks. Those measures comprise restrictive mission modelling for ASAP, a whitelist of the OBC containing all commands allowed for ASAP and a backdoor for the operator as a last resort.
ASAP Check-Out Levels: ASAP is a complex system with higher autonomy features, which can be utilized in different degrees of autonomy. These different degrees are available to the operator by choosing the autonomy mode of ASAP. They are also used to stepwise evaluate the APS. Each check-out level allows to test specific functions to rule out the associated risks, while the influence of the other risks is suppressed at the same time. This is needed due to the versatility of risks through autonomous control through ASAP. Therefore, the following check-out levels will be used in the given order to evaluate ASAP in the SONATE mission.
Classical Payload: The basic mode of operation is using ASAP as a classical payload. This mode will be used to evaluate the basic system functionalities, including telemetry, communication, and storage management at first. Finally, the resulting meta-data of the ASS can be downloaded as classical payload data and will be evaluated on ground. This mode of operation suppresses the influence of any of the elaborated risks. However, it allows the verification of the inputs to the APS, i.e. the correctness of the results of the classification algorithms. However, their actual interpretation as well as the interpretation of the housekeeping data must to be evaluated during the following check-out level.
Plan Only: Once the classical functionalities are verified, the APS will be activated for evaluation purposes. In this mode, the APS runs all three stages of the autonomous planning process except from the synchronization . This means that it generates full plans including the corresponding command lists based on the meta-data of the ASS and the housekeeping data provided by the OBC. However, the generated commands are not synchronized with the OBC and thus actually not executed. Information about all three stages, i.e. the decisions, results of the scheduler and the generated command lists will be available for download as payload data and on-ground analysis. Thus, the risks of invalid and harmful plans and even invalid command lists can by mitigated.
Synchronization Check-Out: Before switching to full autonomy for an experiment time-slot, the critical synchronization mechanism has to be evaluated. To do so, the APS executor will synchronize its command list with the OBC according to the defined protocol, whereat the APS tells the OBC not to execute the commands. By downloading both the lists of the APS and of the OBC as payload data one can verify the synchronization process on ground.
Full Autonomy for Experiment Time-slot: Once an evaluation of all functions including a correct communication between ASAP and the OBC has been successfully conducted, the actual reference scenarios as defined in (Ref. 14) and (Ref. 15) can be operated during the full-autonomy mode. Switching to full-autonomy mode has to be planned beforehand for a specific experiment time-slot, since the plans generated by the APS generally do not consider the command list uploaded via the conventional approach. Because of the unpredictable utilization of resources during autonomous mode, planning a time-slot for full autonomy mode requires new strategies, which will be discussed below.
ASAP Modelled Commands: The reference scenarios for the verification of ASAP as defined cover only a very small subset of the actual capabilities of SONATE. To increase safety of the whole satellite during a time-slot of full autonomy, it is recommended that the configuration of ASAP only models those reference scenarios but not the mission in its entirety. This implies that the commands available to the APS only cover the ones needed for those well-defined reference scenarios and do not contain any possibly dangerous commands (e.g. software updates or similar). The OBC of SONATE implements a symmetrical safety measure as well, in form of a whitelist of commands allowed for ASAP . Thus, the commands available to the APS are a subset of the OBC whitelist.
Additional Command Chain of OBC: The main protective measure of the OBC to prevent malfunctions due to erroneous commanding through ASAP is that another command chain is implemented ( Figure 17). Thus, the processing and management of standard telecommands originating from the human operator can be separated from the processing and management of ASAP commands. Those commands are basically processed in the same way as standard commands as they are also encoded in the same data format. At first, they are interpreted and then, depending on their time-tag, either immediately passed to the executor or to the saver to be stored for later execution. The executor always fetches the next command from the time-tagged list or the one immediately passed from the interpreter and executes it at its due date by passing it to the corresponding subsystem.
Although the processing of both types of commands is so similar, the advantages of the separated processing chains are twofold. Firstly, due to the separation the interferences between both ways of commanding is as low as possible. This means, that also in case of any malfunction of the control through ASAP the chain of classical operations remains functional. The control through ASAP can thus be regarded as a sandbox which does not affect the system in general in early stages of the verification process although eventually it takes over control.
Secondly, the separated chain for ASAP allows to implement further features which are not required, respectively shall not influence, the chain of the classical commands. Besides the other protective measures discussed in the following sections, the notification of ASAP about the processing status of each command originating from ASAP is the most important additional feature of the ASAP command chain.
Furthermore, unlike standard commands all ASAP commands, both immediate and time-tagged, are stored non-volatile for documentation purposes. Those lists can later be downloaded as extended telemetry to verify their correctness and compare them with the original plans of ASAP which are persisted by ASAP itself. This on-ground evaluation of the lists of ASAP commands is an important part of the overall verification of the functionalities of the autonomous control.
Legend to Figure 17:
- Two command chains (solid border: classical; dashed border: autonomous, dotted dashed: interfacing block)
- Different acceptance levels for ASAP commands (depicted by switches)
- ASAP whitelist (attached to ASAP Interpreter)
- Classical command chain remains always active (i.e. operator backdoor)
OBC Acceptance Levels: Symmetrically to the different check-out levels of ASAP the OBC implements different acceptance levels for the command chain of ASAP commands. Those acceptance levels determine to which stage the processing of ASAP commands is run, respectively when it is aborted. This further encapsulates the ASAP command chain as a sandbox without any influence onto the complete system in the lower acceptance levels. The level borders are correlated with the stages of the processing (interpretation, saving, execution) and are depicted as switches in Figure 17. The different levels allow a step by step verification of the command processing before granting ASAP full access for proper full autonomous operations.
The three levels, their relevance for the overall verification process of ASAP as well as the mitigated risks are discussed in the following paragraphs. One has to keep in mind, that one will only proceed to the next acceptance level once the verification steps of the previous one are passed. Commands to enter or leave any of the different levels are of course not whitelisted for ASAP. Furthermore, those acceptance levels are needed despite the implementation of the corresponding check-out levels of ASAP to further increase mission safety. Firstly, in case of severe malfunctions of ASAP also the protective effect of its check-out levels may fail. Secondly, the acceptance level can be set independently from the check-out level, allowing to set it for example in a safe mode procedure and preventing unintended switching to higher levels of autonomy through a single telecommand.
Level 0: Access Completely Denied: This is the default acceptance level. All commands received from ASAP are rejected by the ASAP interpreter even before they are checked against the whitelist. However, the ASAP interpreter notifies ASAP about the rejection due to the low acceptance level according to its notification system. The commands are neither stored in the corresponding command list nor executed. This level is used to run ASAP as classical payload, e.g. to manually take images, especially when configuring ASAP and running early functional tests during LEOP. It hence corresponds to the two lowest check-out levels of ASAP and the operations of ASAP pose none of the identified risks onto the mission. The OBC defaults to this acceptance level especially after reset and when entering the satellite safe mode.
Read & Write Access, Execution Denied: This level may only be entered once it is shown that ASAP behaves well as classical payload and that its generated plans are neither invalid nor harmful. During this level, the ASAP interpreter checks the received commands against the whitelist as well as validates them with the same methods as the standard commands, e.g. the command counter and the time-tag must be in proper ascending order. The ASAP interpreter notifies ASAP about successful unsuccessful whitelist checks and validation, respectively . In case all tests are passed, the commands are saved on non-volatile data storages. They are not executed but the executor notifies ASAP about the rejection due to the low acceptance level at the corresponding command's due time.
This level, especially the protocol of notifications recorded by ASAP and the evaluation of the stored command lists and their comparison with the plans and lists stored by ASAP, allows the verification of the translation algorithm of ASAP as well as the synchronization between ASAP and the OBC. Once verified, the risk of invalid command lists and synchronization failures may be neglected and one can proceed with full autonomous operations. Throughout this acceptance level none of the identified risks are posed onto the mission as all received commands still have no effect onto the satellite.
Level 2: Complete Access: This is the highest acceptance level and corresponds to full autonomous control through ASAP. It may only be entered if all previous verification of ASAP and the processing of ASAP commands were successful. This level is only activated during the corresponding experiment time-slots for full autonomous control and no classically operated activities may be conducted in those time-slots. The ASAP interpreter checks all commands received from ASAP against the whitelist and validates them. In case of success, they are then passed to the data storages. Immediate commands are furthermore passed directly to the executor. Time-tagged commands are fetched from the data storage by the executor and executed at their due date. The interpreter notifies ASAP about the acceptance of the commands, the executor about their invocation and execution. Some subsystems may also provide even more notifications about the commands' execution status.
All identified risks have been eliminated to a neglectable level by the successful verification of all steps while operating in lower acceptance levels. The remaining risks are not severer than for classical operations and are faced with the corresponding methods, e.g. command validation or automatic switch to satellite safe-mode when resource violations are detected by the monitoring and surveillance application, or with the other methods of mitigation, i.e. the whitelist and the operator backdoor.
Whitelist for Commands from ASAP: A quite simple but effective measure to mitigate the risk of harmful plans and/or invalid command list is a whitelist of permitted, uncritical commands. The set of commands in the whitelist is a strict subset of all telecommands defined for SONATE in its telecommand database. The commands to be whitelisted are marked as such in the global telecommand definition database with the dedicated column is ASAP Whitelist whose default value is Boolean false. The OBC searches the onboard copy of the whitelist for every command received from ASAP. Independently from the overall acceptance level, the OBC only accepts commands from ASAP which are elements of the white-list. All other commands are always and promptly rejected. The OBC notifies ASAP about the acceptance respectively the rejection due to non-whitelisting of the command.
One may argue that the risk mitigated by the white-listing can be sufficiently reduced by restrictive definition of activities and commands in the ASAP configuration but this does not hold true for the following reasons. It does address and reduce the risk of harmful plans as well as the risk of invalid command lists due to erroneous definitions. However, it does not address the risk of invalid command lists due to malfunctions of the translation algorithm. It is part of the overall verification process to prove the algorithm's stable performance. Furthermore, a similar argument applies to the risk of harmful plans. Even with restrictive definition of activities and commands a risk remains due to the so far unverified assumption that ASAP only plans activities which are defined. From the point of view of the OBC one has to reject this assumption for a worst-case scenario. Thus, the whitelisting as another protective measure of the OBC may not be neglected.
Operator Backdoor: The last resort during the autonomous control through ASAP for the operator is the command chain for classical operations. In nominal autonomous operations, the operator is not supposed to (i.e. it is forbidden by flight operations directives) control the satellite in the classical manner while ASAP has taken over control. A violation of this directive would be a severe threat as it will cause ASAP's predicted state of resources diverges from the actual course over time and thus in general result in invalid plans generated by ASAP (cf. Section 4). However, the command chain of classical operations always stays active, i.e. commands from ground are always received, interpreted and eventually executed at their due date (provided that they are successfully verified) throughout the whole mission. Hence, while during nominal autonomous control being forbidden, the autonomous control can always be aborted, and the satellite put into a safe state by the operator on ground via classical telecommands.
Implications for the Ground Segment
Besides the space segment also the ground segment, especially the mission planning process and the mission operations, are affected by the autonomous control through ASAP. This is mainly due to the fact that from the point of view of the ground segment the autonomous control leaves the space segment in an unknown state. While resource control capabilities of the mission planning tools predict the space segment's state sufficiently accurate to further classically plan activities in the future, this is obviously not the case for the full autonomous control through ASAP. Hence, each and every activity taking place after a phase of autonomous control might be a threat to the mission as it might over-exploit any critical resource.
This is especially the case for the mission scenario of SONATE as by default the satellite is controlled in a classical manner and autonomous phases occur only from time to time to verify ASAP, 17) resulting in quite many of those critical transitions between autonomous and classical operations. As this problem is expected to be of greater importance for the transition from classical towards autonomous operations in general, it was addressed in the scope of a master's project in the context of the SONATE mission. 18)
Three general concepts are proposed there to face this problem with increased capabilities of mission planning tools. For SONATE we will follow the concept of Safe Planning. Basically, this approach discourages all classically planned activities following a phase of autonomous control until the space segment's state is assessed during the next downlink opportunity. This results in a significant idle time (Figure 18) after each autonomous phase causing suboptimal utilization of the space segment. But as SONATE's main objective is to safely demonstrate the autonomous control through ASAP and one does not focus on optimal resource utilization, this is acceptable for the mission.
In contrast to the proposal of (Ref. 18), SONATE will not implement the extensions for the mission planning tool but realize the concept of Safe Planning by directives of the flight manual for the planning engineer. This means, that the planning engineer is prohibited to schedule activities in the idle time but will not be assisted by the mission planning tool to follow this rule. This decision was taken for two reasons. Firstly, in order to keep the operator backdoor open, also the ground segment has to allow to schedule at least emergency procedures even during phases of autonomous control. This opposes the concept of Safe Planning and would require special rules for those special cases. Secondly, the current version of the mission planning tool for SONATE does not support Safe Planning. Due to the limited resources of the development team, it was decided that the implementation effort outweighs the advantages compared to the realization through directives for the planning engineer. This rating can of course be reverted in the course of time and the features of the mission planning tool might get implemented later during the mission.
Figure 18: Illustration of the Safe Planning concept (adapted from ). The dashed classical planned timeline entry is disallowed as it is in the idle time. The first uplink opportunity cannot be used as it is before the first downlink opportunity (image credit: University of Wuerzburg)
Another implication for the mission operations during autonomous operations affects the availability and the readiness of the ground segment for radio links towards the space segment. During classical operations the ground contacts are planned well in advance for both the space and ground segment. This includes to guarantee the availability and readiness of the ground segment, e.g. correct antenna pointing. One may forego any ground contact opportunities for different reasons, like lack of operational personal, ongoing maintenance work of the ground segment, as the schedule is synchronized between space and ground segment. In contrast, this is not the case during phases of autonomous operations. ASAP can dynamically decide, e.g. depending on the fill-level of data storages, whether to utilize a ground contact opportunity and establish a link, or not. To eliminate the risk of data-loss the ground segment has to guarantee the availability and readiness for ground contacts for every opportunity during phases of autonomous operations. Vice versa, the operational personnel shall not panic if no link is established during such a ground contact opportunity as ASAP could simply have decided to forgo the opportunity for the benefit of some other activity.
Figure 19: Photo of the SONATE mission control room (image credit: University of Wuerzburg)
1) Thomas Rapp, Oleksii Balagurin, Tom Baumann, Hakan Kayal, Anselm Krainovic, Tobias Schwarz, Harald Wojtkowiak, "Preparing SONATE for Autonomous Control Through ASAP," Proceedings of the 69th IAC (International Astronautical Congress) Bremen, Germany, 1-5 October 2018, paper: IAC-18.B4.3.13, URL: https://iafastro.directory/iac/proceedings
2) Tobias Schwarz, Oleksii Balagurin, Tom Baumann, Gerhard Fellinger, Hakan Kayal, Thomas Rapp, Harald Wojtkowiak, "SONATE-3U nanosatellite mission for highly autonomous payloads," 4S (Small Satellites, Systems & Services) Symposium, Sorrento, Italy, May 28-June 1, 2018
3) Hakan Kayal, Oleksii Balagurin, Kirill Djebko, Gerhard Fellinger, Tobias Greiner, Frank Puppe, Alexander Schneider, Tobias Schwarz, Harald Wojtkowiak, "SONATE - a nanosatellite for autonomy," Proceedings of the 68th IAC (International Astronautical Congress), Adelaide, Australia, 25-29 Sept. 2017, paper: IAC-17.B4.3.13, URL: https://iafastro.directory/iac/proceedings/IAC-17
4) Harald Wojtkowiak, Oleksii Balagurin, Kirill Djebko, Gerhard Fellinger, Tobias Greiner, Hakan Kayal, Alexander Schneider, Tobias Schwarz, "Autonomous mission operation onboard nanosatellite SONATE," Proceedings of the 68th IAC (International Astronautical Congress), Adelaide, Australia, 25-29 Sept. 2017, paper: IAC-17.B6.2.2, URL: https://iafastro.directory/iac/proceedings
5) Harald Wojtkowiak, Oleskii Balagurin, Gerhard Fellinger, Borja Garcia, Hakan Kayal, "ASAP: Autonomous Dynamic Scheduling for small satellites," Proceedings of the 64th International Astronautical Congress (IAC 2013), Beijing, China, 23-27 September 2013, paper: IAC-13-B4.3.3
6) H. Kayal, B. Balagurin, H. Wojtkowiak, " ASAP: A Novel Autonomous Image Sensor for Event Detection and On Boad Planning System," 4S ( Small Satellites, System & Services Symposium), Portorož, Slovenia, 2012
7) Gerhard Fellinger, Kirill Djebko, Eric Jaeger, Hakan Kayal, Frank Puppe, Simon B. Stier, "ADIA++: An Autonomous Onboard Diagnostic System for Nanosatellites," AIAA Space and Astronautics Forum and Exposition, Long Beach, CA, USA, 2016, https://doi.org/10.2514/6.2016-5547
8) G. Fellinger, E. Jäger, K. Djebko, O. Balagurin,, H. Kayal, F. Puppe, A. Schneider, T. Schwarz, H. Wojtkowjiak,"ADIA-L: Implementation and Integration of a Model-Based Autonomous Diagnostic System as Payload for the Nanosatellite Mission SONATE, " Proceedings of the 68th IAC (International Astronautical Congress), Adelaide, Australia, 25-29 September 2017, paper: IAC-17.B6.IP.5, URL: https://iafastro.directory/iac/proceedings
9) Oleksii Balagurin, Gerhard Fellinger, Hakan Kayal, Tobias Schwarz, Harald Wojtkowiak, "A Novel Nano Satellite Mission to Demonstrate Autonomous System Technologies," Proceedings of the 4S (Small Satellites, System & Services) Symposium, 30 May – 3 June 2016, Valletta, Malta
10) Stephen Clark, "Soyuz rocket and Fregat upper stage deliver 33 satellites to three different orbits," Spaceflight Now, 5 July 2019, URL: https://spaceflightnow.com/2019/07/05/soyuz-rocket-and
11) "SONATE," Chair of Computer Science VIII - Aerospace Information Technology, University of Würzburg, URL: http://www8.informatik.uni-wuerzburg.de/en/wissenschaftforschung/sonate/
12) 32 small spacecraft ready for launch from the Vostochny Cosmodrome as secondary payload," Glavkosmos, 28 June 2019, URL: http://glavkosmos.com/en/news
13) "Exolaunch has integrated 28 smallsats for July Soyuz launch," Space Daily, 3 July 2019, URL: http://www.spacedaily.com/reports
14) Harald Wojtkowiak, "Planungssystem zur Steigerung der Autonomie von Kleinstsatelliten," PhD Dissertation at Julius-Maximilians-Universität Würzburg, Germany, 2018, URL: https://www.researchgate.net
15) Harald Wojtkowiak, Oleksii Balagurin, Kirill Djebko, Gerhard Fellinger, Tobias Greiner, Hakan Kayal, Alexander Schneider, Tobias Schwarz, "Autonomous Mission Operations Onboard Satellite, SONATE," Proceedings of the 68th IAC (International Astronautical Congress), Adelaide, Australia, 25-29 Sept. 2017, paper: IAC-17-B6.2.2, URL: https://iafastro.directory/iac/proceedings/IAC-17/IAC-17/B6/2/manuscripts/IAC-17,B6,2,2,x37561.pdf
16) Harald Wojtkowiak, Oleskii Balagurin, Gerhard Fellinger, Borja Garcia, Hakan Kayal,"ASAP: Autonomous Scheduling for small Satellites," Proceedings of the 64th International Astronautical Congress (IAC 2013), Beijing, China, 23-27 September 2013, paper: paper: IAC-13-B4.3.3
17) Oleksii Balagurin, Gerhard Fellinger, Hakan Kayal, Tobias Schwarz, Harald Wojtkowiak, "A Novel Nano Satellite Mission to Demonstrate Autonomous System Technologies," Proceedings of the 4S (Small Satellites, System & Services Symposium), Valletta, Malta, 30 May – 3 June 2016
18) Thomas Rapp, "Development and Implementation of a Mission Planning Tool for SONATE," Master Thesis, Luleå University of Technology, 2017, URL: http://ltu.diva-portal.org/smash/get/diva2:1161015/FULLTEXT01.pdf
The information compiled and edited in this article was provided by Herbert J. Kramer from his documentation of: "Observation of the Earth and Its Environment: Survey of Missions and Sensors" (Springer Verlag) as well as many other sources after the publication of the 4th edition in 2002. - Comments and corrections to this article are always welcome for further updates (firstname.lastname@example.org).