MASTER'S THESIS. Automation of Ground Station Scheduling for the Cluster Mission using an Artificial Intelligence Framework. Nicolas Färber 2016

Transcription

1 MASTER'S THESIS Automation of Ground Station Scheduling for the Cluster Mission using an Artificial Intelligence Framework Nicolas Färber 2016 Master of Science (120 credits) Space Engineering - Space Master Luleå University of Technology Department of Computer Science, Electrical and Space Engineering

2 Automation of Ground Station Scheduling for the Cluster Mission using an Artificial Intelligence Framework Master Thesis in the course of the study programme Master in Space Science and Technology by Nicolas Färber born on 10. Juli 1990 in Würzburg Julius-Maximilians-Universität Würzburg Department of Computer Science Aerospace Information Technology Prof. Dr.-Ing. Hakan Kayal M.Eng. Harald Wojtkowiak Luleå Tekniska Universitet Department of Computer Science, Electrical and Space Engineering Dr. Jingsen Chen European Space Operations Centre Human Space Flight and Operations Cluster-II Spacecraft Operations Unit Bruno Sousa Submitted on: 15. September 2015

3

4 Declaration I hereby declare that this thesis is entirely the result of my work except where otherwise indicated. I have only used the resources given in the list of references. Würzburg, 15. September 2015 (Nicolas Färber)

5

6 Abstract In the course of simplifying and automating mission operation for the Cluster-II satellites of the European Space Agency (Esa), a tool for automated ground station pass scheduling has been implemented. The large number of constraints involved in pass scheduling requires a member of the Cluster-II flight control team to dedicate about 1.5 working days to planning and scheduling activities during one week. Due to the complexity of the problem, the resulting plans are often not optimal which results in higher costs for tracking hours than necessary. Esa s Advanced Planning and Scheduling Initiative (Apsi), developed at the European Space Operations Centre (Esoc), is an approach to introduce automation and advanced technologies to tackle such scheduling and planning problems. The software framework is capable of solving and optimising scheduling problems by utilising artificial intelligence for resource driven planning. The Cluster-II scheduling constraints were analysed and modelled in accordance with the domain and problem languages provided by Apsi. A graphical user interface allows the operator to compare the produced solutions in terms of predefined criteria. Additionally, to integrate the tool flawless in the daily mission operation and its internal mission platform ClusterWeb, interfaces preand post-processing the information for the scheduling tool have been developed and integrated to ClusterWeb. Preliminary results of automatically generated plans provide an insight in the current development process of the framework and point out its behaviour. Based on these results and the experiences made so far, it can be expected that the tool will have a big impact on mission operation for Cluster-II once the Apsi framework is fully optimised and the scheduling tool can be deployed in routine operations. i

7

8 Contents 1. Introduction Mission Overview Space Segment Ground Segment Scheduling Problem of Cluster-II Purpose and Scope Mission Operation Platform and Planning Framework Cluster-II Mission Planning Interface ClusterWeb Advanced Planning and Scheduling Initiative Overview Provided Interfaces for Domain and Problem Models Case Studies Related Work Mission Planning and Scheduling Constraints and Requirements Scheduling Goals Scheduling Properties Inputs Pass Types Periodicity Constraints Ground Station Constraints Science Driven Constraints Operational Constraints Orbital Constraints Models Solid State Recorder Link Budget Scheduling Tool Requirements Compatibility Configurability Quality Measurement Analysis of Goals, Requirements and Resources Scheduling Goals Capabilities of APSI Interfaces to and from APSI Available Planner iii

9 Contents Domain and Problem Modelling Cluster-II Planning Constraints Domain Constraints Scenario Constraints Post-Processing of Constraints User Interaction Quality Measurement Cluster-II Scheduling Tool Tool Deployment and Workflow Design of the Domain Model Component Types and Timelines Synchronisations Implementation Interfaces Domain Definition Language Modelling Problem Definition Language Modelling Results Outlook and Further Work Conclusion 73 A. Ground Station Plan Evolution and Analysis 74 B. Multiple-Spacecraft Per Aperture 77 C. APSI Input Tool Screenshots 79 List of Figures 81 List of Tables 83 Bibliography 85 iv

10 Acronyms Agc Ai Aod Aos Apsi Aspen Cis Clu1,2,3,4 Ddl Dsf Dsn Edi Eps Esa Esoc Estrack Eumetsat Europa Fct Fd Gui Hbr Hk Hpa Hpm Hso-Osa Jsoc Kru Lbr Los Lpm Ltef Mps Msg Automatic Gain Control Artificial Intelligence Angle Of Deviation Acquisition Of Signal Advanced Planning and Scheduling Initiative Automated Scheduling and Planning Environment Cluster Ion Spectrometry Cluster 1, 2, 3, 4 (spacecraft) Domain Definition Language Detailed Schedule File Deep Space Network Electron Drift Instrument ESTRACK Planning System European Space Agency European Space Operations Centre European Space Tracking Network European Organisation for the Exploitation of Meteorological Satellites Extensible Universal Remote Operations Planning Architecture Flight Control Team Flight Dynamics Graphical User Interface High Bit Rate House Keeping High Power Amplifier High Power Mode Advanced Mission Concepts and Technologies Office Joint Science Operations Centre Kourou (ground station) Low Bit Rate Loss Of Signal Low Power Mode Long Term Event File Mission Planning System Meteosat Second Generation v

11 Acronyms Msp Mspa Nasa Nno Obdh Obrq Pdl Per Plasma Ssr Stef Tc Tda Tm Trf Ttq Vl2 Wbd Wec Maspalomas (ground station) Multiple-Spacecraft Per Aperture National Aeronautics and Space Administration New Norcia (ground station) On-Board Data Handling Observation Request file Problem Definition Language Perth (ground station) Plan Space Multi-solver Application Solid State Recorder Short Term Event File Tele-Commands Telemetry Data Acquisition (mode) Telemetry Timeline Representation Framework Time-Tag Queue Villafranca (ground station) Wide Band Data Wave Experiment Consortium vi

12 Chapter 1. Introduction The Cluster-II satellite constellation is a cornerstone mission in the European Space Agency s Horizon 2000 missions programme. The tetrahedral formation of the four identical, spin-stabilised satellites allows them to do precise in-situ measurements of the Earth s magnetosphere in three dimensions. In 1996, the original Cluster mission was launched with the first Ariane 5 rocket from Kourou, French Guiana, but ended already after 37 seconds as aerodynamic loads forced the destruction of the rocket and the satellites, respectively.[1] Fig. 1.1.: Graphical illustration of the four Cluster satellites, displaying parts of the subsystems visible in the foreground. (Credit: Esa) Together with the initial four Cluster satellites, a fifth satellite was developed which was intended to be used as an engineering model while the others are in space. Still in 1996, it was decided to send this engineering model to space. In 1997 it was finally decided that the mission objective is so important, that replacements for the three remaining satellites should be constructed. In July and August 2000 the rebuilt satellites were launched in pairs with two Soyuz rockets from Baikonur Cosmodrome, Kazakhstan. After a six month phase of orbit insertion and instrument testing, routine science operation started in February

13 Chapter 1. Introduction The spacecraft were designed for a 2 years timespan of routine science operations. After several mission extensions, it has been approved to operate the quartet until the end of 2016, with a further mission extension up to the end of 2018 in preparation.[2] The unbroken interest of scientists in the data provided by Cluster 1 is also reflected in a constant publishing rate of papers and an overall number of 2653 Cluster referred publications until the end of June Mission Overview Space Segment The mission s objective is to map the electromagnetic environment of Earth in space and time. Especially regions where solar particles interact with the Earth s magnetic field like the polar cusps, the bow shock and the magnetotail are of high interest. For this, the spacecraft are equipped with eleven instruments from European and American institutions. To be able to compare the results from the measurements of the four spacecraft in space and time, the instruments on all spacecraft need to be identical and operated simultaneously. When the apogee of the formation is facing the Sun, the highly eccentric orbit of about 0.6 with an apogee height of about km allows observations in the solar wind and at the Earth s bow shock. Magnetic reconnection in the Earth s magnetotail can be investigated when the apogee is directed towards the Earth s night side (cf. Figure 1.2). Multiple formation changes over the past years enabled the measurement of scientific data in different scales and constellations. The closest distance between two spacecraft was reached in 2013 with a separation of only 4 km between Clu3 and Clu4. Over the years, the spacecraft s thermal insulation and especially the solar arrays degraded heavily. The provided solar array power has reduced to a range of 150 W to 170 W (varying between the different spacecraft, depending on the season and the distance to the Sun and to the Earth) from an initially provided power of over 270 W. Gravitational forces reduced the perigee height since launch and resulted in an orbit where the spacecraft crossed the inner radiation belt from 2008 until This accelerated the degradation of the solar panels even further (see [3]). To be able to operate all scientific instruments, it is necessary to save power on non-essential subsystems of the satellites. As a consequence, heaters are turned off and the High Power Amplifier (Hpa) for communication is operated in Low Power Mode (Lpm) which reduces the strength of the transmitted signal during routine operations. After the batteries outlived their designed life cycle, cracks appeared and leaking gas caused small drift velocities and contamination of subsystems. As precautional measures the batteries had to be declared as non-operational. This has a major influence on the operation of the spacecraft during eclipse periods where the spacecraft need to be switched off before eclipse and recovered afterwards. Furthermore, new strategies needed to be developed which prevent the spacecraft from cooling down 2 1 For the reason of simplification and a better readability, the suffix -II will be dropped in the further proceeding of the document.

14 1.1. Mission Overview Fig. 1.2.: Illustration of Cluster with apogee facing sun and the apogee in the magnetotail in (Credit: Esa) too much during periods of almost three hours in the Earth shadow (for further information see [4] and [5]). In routine operations, the scientific and housekeeping data is stored on a Solid State Recorder (Ssr) with a beginning of life capacity of 7.5 Gbit which is still fully available and did not experience any degradation. The Ssr is organised as a first-in first-out ring memory with a record pointer and a reproduce pointer. The record pointer can never pass the reproduce pointer. This means, if the memory is full, the record pointer pushes the reproduce pointer in front of it and overwrites the first recorded data or stops entirely to record new data. To avoid the loss of scientific data, the produced data should be dumped before the memory capacity is exhausted Ground Segment The Cluster mission is controlled and operated from the European Space Operations Centre (Esoc) in Darmstadt, Germany. The main responsibility for the health and care of the spacecraft lies with the Flight Control Team (Fct), consisting of engineers, analysts and spacecraft controllers. Mission operation and planning makes use of an internal website called ClusterWeb which was developed by the Fct itself and is constantly updated with new functionalities. This mission operation platform is unique within Esoc and facilitates the process of planning and coordination for the Fct immensely. Science operation is planned and coordinated by the Joint Science Operations Centre (Jsoc), located in Chilton, United Kingdom. The science plan includes for example on and off times for certain instruments, as well as time frames in which the resolution of scientific measurements is increased and therefore the production 3

15 Chapter 1. Introduction rate of data is higher. The burst science mode is mainly used in areas where scientists expect special phenomena in the magnetosphere like the bow shock or close to the polar cusps. This science plan is incorporated in the overall ground station schedule under the consideration of all constraints and requirements from the platform by the Fct. Aside from the input of Jsoc, the ground station plan also depends on the input of the Flight Dynamics (Fd) team and on ground station availabilities. Ground station passes enable the Fct to download the scientific data from the spacecraft and check the overall health of the satellites. Furthermore, the upload of time tagged Tele- Commands (Tc) is performed during ground station passes. After the scientific data has been dumped from the spacecraft, it is possible to access them online via FTP within hours. To be able to communicate with the satellites, a variety of ground stations are provided by the European Space Tracking Network (Estrack) of Esa and by the Deep Space Network (Dsn) of Nasa. Currently, Cluster is able to use the 15 m Estrack ground station antennas at Maspalomas (Msp), Villafranca (Vl2), Kourou (Kru) and Perth (Per) routinely, however Perth will be closed down in 2016 and Kourou is mainly used by Esa s Xmm mission. The deep space ground station in New Norcia (Nno) can also be used in 2015, but the uplink of tele-commands will not be available any more in Dsn ground station times were only provided on an irregular basis. These time frames can usually not be moved but have the advantage of a big satellite dish, which allows downlink in high bit rate (Hbr). The routine support of Dsn has stopped in 2015 (for further details on the evolution of the ground segment, see [6]) Scheduling Problem of Cluster-II The main objective of the ground station scheduling is to keep the Ssr fill level as low as possible and avoid any overwriting of scientific or housekeeping data. On the other hand, it should be avoided to empty the Ssr completely to not waste tracking hours. For this, a ground station plan with the exact contact times to the four spacecraft is created and revised by the Fct on a weekly basis. The ground station pass plan initially provided by the Estrack Planning System (Eps) does not fully satisfy the constraints and requirements of the Cluster mission. The reason for this is that specific and important information like the Ssr fill level of the spacecraft or the science modes cannot be made available in advance to Eps. Therefore heavy manual interaction and manipulation of the original plan is required, which makes an investment of 1.5 man-days for one of the members of the Fct per week necessary. This also requires a lot of trial and error, based on the experience of the operator. Due to the large number of constraints involved, the process of scheduling is very complex and the solution is often not optimal (for a comparison of a manually created plan and a schedule from Eps, see Appendix A). As the Hpa is in Lpm in routine operations due to insufficient power, the link budget plays an increased role for the scheduling of ground station passes. Cluster uses mostly satellite dishes with a diameter of 15 m (except for Nno and Dsn stations) 4

16 1.3. Purpose and Scope which does not allow a downlink in Hbr ( bps) close to apogee when the slant range between ground station and satellite is very high with about km. Hence, Telemetry (Tm) is mostly dumped in Low Bit Rate (Lbr, bps). So, to be able to dump the same amount of data, more passes and tracking hours are required. This is accompanied with increasing costs for downloading the data as each tracking hour has to be paid to Estrack. Furthermore, Dsn support for the Cluster mission ended in mid 2015 which reduces the number of available Hbr pass opportunities Purpose and Scope The purpose of this thesis is to analyse the requirements of Cluster mission planning and scheduling and to describe the implementation of a software tool which automates the process of creating ground station plans. The tool is based on a software framework called Advanced Planning and Scheduling Initiative (Apsi) which is developed by the Advanced Mission Concepts and Technologies Office (Hso-Osa) at Esoc. The framework provides the functionality to model and solve planning and scheduling problems. A detailed analysis of the Cluster scheduling constraints and requirements has been conducted, followed by a design proposal according to the results of the analysis. Finally, constraints have been modelled and implemented in the given modelling and programming languages of Apsi and ClusterWeb. A flawless integration of the scheduling tool in the planning environment enhanced the overall planning process without changing the work flow in a significant way. For this, interfaces from ClusterWeb to the scheduling tool and vice versa have been implemented in php, the programming language ClusterWeb is based on. Additionally, it was necessary to implement a dedicated Graphical User Interface (Gui) for handling the scheduling tool itself which is based on Java, the programming language of the framework. The scope of the thesis includes the analysis of requirements for all interfaces and their implementation. The necessity of new components and additional solvers for the Apsi framework emerged during the analysis of the Cluster scheduling constraints. The requirements for new components have been discussed in close cooperation with Hso-Osa. The implementation of new components for the Apsi framework has completely been done by Hso-Osa and is not part of this thesis. The scope of this thesis ends when the modelled constraints are provided to Apsi by the supplied APIs of the framework and fine-tuned such that they provide solutions. As a result, an automatically produced plan is presented. It gives an overview of how the solver works and what the current progress of the framework is. At last, an outlook for the Cluster scheduling tool is given and necessary steps for future development are pointed out. Furthermore, a lookout how the scheduling tool fits in a more and more automated environment in future mission operation is presented. 5

17 Chapter 2. Mission Operation Platform and Planning Framework The automated scheduling tool is part of the overall Cluster mission planning platform ClusterWeb and is based on a framework called Advanced Planning and Scheduling Initiative (Apsi) which is utilising Artificial Intelligence (Ai) in order to model and solve planning problems and generate schedules. An overview of the ClusterWeb platform and its functionalities is given in the section 2.1 below. Furthermore, an overview of the artificial intelligence framework Apsi is given in section 2.2. This also includes a more detailed description of its capabilities, provided modelling languages and interfaces, with a short presentation of already existing use cases of Apsi and related work in the end Cluster-II Mission Planning Interface ClusterWeb Despite the fact that the Cluster Mission is already ongoing for 15 years, the Fct constantly tries to find ways, tools and concepts to ease mission planning and monitoring. A tool which improved the workflow significantly is the internal mission operations website called ClusterWeb introduced in The web page is an inhouse development of the Fct, tailored for the requirements of the Cluster mission. Over the years, many functionalities and tools have been added and extended to create a unique and powerful platform which is heavily used by the Fct for the daily operations. It has immensely enhanced the way how satellite operations are done for Cluster. New features are constantly added and lead to a continuous improvement of the web page. The web page itself and most of its tools are programmed in php, html and javascript. ClusterWeb is deployed on an Apache web server with an attached MySQL database which contains all necessary information for Cluster mission operations. The database must be updated regularly with data from a number of different interfaces. This includes for example spacecraft position data, orbital events, ground station visibilities provided by flight dynamics and operational sequences with commands for the scientific instruments. Furthermore, initial ground station plans are provided by Eps and imported to the database in the same way. The most important element of ClusterWeb is displayed in Figure 2.1. It shows a 6

18 2.1. Cluster-II Mission Planning Interface ClusterWeb Fig. 2.1.: Ground station schedule representation for Cluster passes in ClusterWeb. timeline representation of the ground station passes for all four Cluster spacecraft. Passes are depicted as blue boxes and display the Acquisition Of Signal (Aos) and Loss Of Signal (Los) times of the spacecraft. Furthermore the boxes are given the name of the ground station which is communicating with the satellite. A profile chart included in this view depicts the on-board Ssr fill level evolution for the different Cluster satellites. The red profile line is a representation of the data which has been already dumped from the spacecraft s memory and is derived from the Tm database. The green profile line is a forecast of the Ssr fill level and is based on models described later. The steepness of the slope of both representations depends on the dump rate of the booked passes and the Telemetry Data Acquisition (Tda) mode and therefore the data production rate of the scientific instruments (for an detailed explanation of the different science modes and their production rate, please see section and for further information on the Ssr model, see section 3.4.1). The Tda modes are represented by the colouring of the background of each spacecraft timeline. According to the evolution of the Ssr fill level ground station passes have to be assigned to the multiple spacecraft to avoid an overflow and overwriting of the onboard memory. Ground station passes can only be scheduled within the available visibilities and only if these ground station visibilities are not booked by other spacecraft. Ground station visibilities can be also displayed in the view of Figure 2.1 by clicking the GS visib button on the right pane. Additionally, it has to be ensured that the signal strength within a visibility is high enough to allow a downlink. Based on the signal-to-noise ratio, a prediction on the download bit rate during a ground station visibility can be provided. Figure 2.2 shows the screenshot of the bit rate forecast tool deployed in ClusterWeb. It displays the signal-to-noise ratio for a Clu1 visibility over the ground station Vl2. The top line of the graphic (starting with Bitrate prediction... ) gives the current spacecraft 7

19 Chapter 2. Mission Operation Platform and Planning Framework Fig. 2.2.: Bit rate forecast of a Villafranca visibility with spacecraft 1. configuration which can be changed by the control buttons in the bottom. It can be observed that the available downlink bit rate changes from Lbr to Hbr in the middle of the visibility with a decreasing slant range (orange line) and an increasing elevation (blue line) (for more details on the model of the link budget, see section 3.4.2). Once a desirable pass opportunity has been identified, it is possible to create a new ground station pass by using the sliders to adjust Aos and Los times and clicking the Create pass button afterwards. Once a pass is created, detailed information about the spacecraft configuration and pass properties are provided by the user interface depicted in Figure 2.3. The view provides details about the pass start and end, a forecast of the bit rate and derived from that a forecast of the Ssr fill level at the beginning and end of the pass. Additional important information for the pass scheduling are the details about Tda modes during the visibility and ground station bookings of other spacecraft within a certain time range before and after the visibility. The creation of new passes or any manipulations of pass details are stored in the ClusterWeb database. From the changes done on the database, schedule updates are created and transmitted to the scheduling office on a weekly basis via an interface implemented in ClusterWeb. ClusterWeb provides many more tools which are used for other aspects of mission operations than scheduling. 8

20 2.2. Advanced Planning and Scheduling Initiative Fig. 2.3.: Pass info for a ground station pass of spacecraft 2 over Maspalomas Advanced Planning and Scheduling Initiative Apsi is a software framework, written in Java, for solving planning and scheduling problems. It is designed to allow rapid prototyping, design and the fast implementation of planning and scheduling applications. The framework is a development of the Advanced Mission Concepts and Technologies Office (Hso-Osa) at Esoc. The idea of developing an Ai-based framework for planning and scheduling emerged from the success of previously deployed scheduling tools (Mexar, Mexar2 and Raxem) for Esa s Mars-Express mission and the potential of Ai-based scheduling for other space applications. To avoid a long and resource demanding development process for future tools, it was decided to create a framework which is capable of solving planning and scheduling problems in multiple domains and equip it was different solvers and functionalities.[7] 9

21 Chapter 2. Mission Operation Platform and Planning Framework B [lb,ub] prod. con. ub A(?z) C(?y)?z >?y (a) State variable. o lb t 1 t 2 h t (b) Consumable resource. Fig. 2.4.: Representation of a state variable and a resource profile. An overview of Esa s Apsi framework is given below. Furthermore, principal functionalities and capabilities are explained. A presentation of already existing planning tools which are using Apsi is given and similar scheduling and planning frameworks developed by Nasa are explained in the last part of this section Overview Apsi utilises the timeline-based approach of modelling planning and scheduling problems. In order to model physical properties and features of a system, entities are introduced. To represent the evolution of such an entity over time, values of this entity are posted on a timeline. The timeline starts at an origin o and has a horizon h which determines the end of the timeline. Depending on the type of the timeline, the rules for the values are different. Two examples for an entity representation are state variables and resources (cf. Figure 2.4). State variable timelines can only inherit one distinct state at a time. Transitions between the different states of a variable have to be defined according to the model of the physical properties it should describe. Furthermore, it can be specified if states need to have a minimum and a maximum duration (cf. the duration for the state B in Figure 2.4a has a lower bound lb and an upper bound ub) or if certain conditions have to be fulfilled before a transition can be done (this is also called a guard, see states A(?z) and C(?y) in Figure 2.4a where the condition?z >?y has to be fulfilled to allow the transition from A to B). A simple example for the appropriate usage of a state variable is the representation of the state of a door. A door can either be open or closed, but it can not inherit both states at the same time. By checking the status of the timeline, it can be identified if the door is open or closed at a given time. Additionally to the state, the variable can inherit a parameter value. In the example from above, a parameter of the state value can represent if the door is locked or not. Before a transition from a closed state to an open state of the door (or vice versa), it has to be checked if the door is locked or not. Only if the defined guard allows the transitions (not locked), a change of the state variable is possible. On the other hand, resource timelines model physical systems where a numerical value with an upper and a lower bound needs to be represented. The example displayed in Figure 2.4b is a representation of a more distinct resource, called con- 10

22 2.2. Advanced Planning and Scheduling Initiative sumable resource. Changes on the profile of a consumable resource are called either production if the value of the resource increases (see Figure 2.4b from o until t 1 ) or consumption when the value of the resource decreases (see Figure 2.4b from t 1 until t 2 ). 1 Furthermore, it has to be considered that the resource value can never be lower than the specified lower bound lb and higher than the upper bound ub. An example of a consumable resource is any kind of tank containing liquid, like a rain water tank. In that specific example, the opening and release of rain water could be modelled as a consumption, whereas the filling of the water tank while it is raining can be modelled as a production. Considering the release valve is mounted at a certain height of the tank, the fill level of the tank can never be less than the height of the valve marking the lower bound of the resource. The maximum capacity of the resource is given by the volume of the tank and marks the upper bound. The example of the water tank also reveals that it is necessary to model relations between different components of the whole system. It was concluded that a water consumption corresponds to an open valve. The status of the valve can be modelled as a state variable on a timeline while the water fill level is a resource on another timeline. The relation between these two timelines is denoted as a synchronisation. The behaviours of the single components and how they relate to each other are constituted in a so called domain theory. This means that the modelling of the physical properties and systems and the way how different systems influence each other are described in the domain. Usually a domain is defined by multiple timelines with different state variables and/or resources which are synchronised to each other. All actions and events located on the timelines have to comply with the constraints modelled in the domain, otherwise the presented scenario is not a solution of the domain. For a more detailed explanation and description of the single components, like state variable, resources, synchronisations, the domain theory, problems and solutions modelling please refer to [8]. All these concepts are formalised in the Timeline Representation Framework (Trf). The Trf represents the base frame and is designed to offer a very high generalisation and compatibility to a wide variety of planning problems. It provides the basic functionalities, data types and structures to implement the components specified above. Further information about the Trf can be found in [9]. Figure 2.5 shows the architecture of the Apsi framework at it s highest level. At its core, the framework consists of a plan database which stores all provided information about time, data, timelines, etc.. The solver database is the other core component of the framework and contains the search space of a solving process with its found solutions and also with not successful (inconsistent) plans. The light blue boxes represent services and engines which provide the basic functionalities of the Apsi framework, like the extraction of timelines, reasoning on timelines, querying of the search space, execution of timelines and many more. To be able to interface the framework, several APIs (pink-coloured) are provided. The APIs of highest interest 1 As already mentioned, it has to be considered that a consumable resource is stepwise constant which means that only absolute values can be consumed or produced at a time instant. A modelling of more complex slopes can be very complicated. For this reason a new resource has been introduced in the course of this project which is further explained in section

23 Chapter 2. Mission Operation Platform and Planning Framework Fig. 2.5.: The architecture of the APSI framework. (Credit: Esa) for this thesis are located on the left side of the graphic and constitute the interfaces to the model of the problem domain and the specific problem itself Provided Interfaces for Domain and Problem Models The Apsi framework provides several ways to make the problem and its domain available to its engines. The properties of a physical system can be provided to the framework, in terms of the components specified above, in three different ways. The domain and problem modelling can be done in the following ways: Java code: Apsi provides an API which allows to model the problem and the domain directly in Java. For this, multiple object classes and constructor functions are available. According to the model, components, transitions and further properties are specified in Java code. XML files: A XML parser allows to create models for problems and domains outside of the Apsi framework. This would result in one XML file for the domain and one XML file containing the initial information of the problem itself. The provided API interprets the supplied XML file with the system model and converts it to Java objects, on which it can be reasoned by the framework. DDL/PDL files: Similar to the problem and domain definition using XML files, Apsi provides parsers for external files based on the Apsi dedicated Domain Definition Language (Ddl) and Problem Definition Language (Pdl). State variables, resources, timelines, etc. are described in the special syntax of the two file types. The files are interpreted by parsers and Java objects are created accordingly. (For a more detailed description and analysis of Ddl and Pdl files, refer to ) 12

24 2.2. Advanced Planning and Scheduling Initiative Once the properties of the physical system are specified and loaded into Apsi, they are stored in the plan database. From that point on, the data is available to the reasoners and solvers of the framework and the process of solving the scheduling problem can be initiated Case Studies Esa s Mars-Express mission utilises Ai-based tools to plan the downlink of the spacecraft s different on-board memories (Mexar, Mexar2) and to plan the uplink of commands to the spacecraft (Raxem, Raxem2). From the experiences made during the development of these tools (see [7]), the Apsi framework emerged. MrSPOCK is the first Apsi-based tool and is also used for mission planning of the Mars-Express mission. Whereas Mexar2 is handling the downlink problem and Raxem2 is responsible for managing the uplink of Tc, MrSPOCK coordinates the operational plan and the science requests. This means, that MrSPOCK is creating a long term plan for the satellite operations under the consideration of the inputs from the principle investigators and the mission operations team. The principle investigators are the scientists responsible for the payloads on board of the spacecraft and decide where and when to do scientific measurements in the Mars orbit. For example, surface observations are preferably conducted at perigee as the distance to ground is at a minimum at this time. When the spacecraft is passing from perigee to apogee or vice versa, communication to one of the ground stations on Earth can be established. At apogee, maintenance of the spacecraft is done. The coordination of activities requested by the scientists and necessary activities from an operational perspective required iterative consultation of the operators and scientists to come to an appropriate solution for both parties. The objectives discussed by scientists and operators are now specified in the domain model of MrSPOCK. This means, orbit events like apogee and perigee are made available to the tool, as well as ground station visibilities of the spacecraft. With these information available, the scheduling tool is able to produce different solutions according to a predefined optimisation function f(s) of a solution S. An optimal solution is assessed by finding the best compromise between science, downlink, uplink opportunities and an indicator for the uplink of Tc without delay. A satisfying solution can then be selected by comparing multiple solutions with the help of a dedicated Gui. The interface lists the n best solutions and allows a comparison of the different quality measures for each solution. Once a suitable solution is found, the schedule containing the planned activities can be exported to the required file format.[10] Related Work Apsi is not the first framework which tries to establish Ai-based planning and scheduling tools in the space domain. With the Automated Planning and Scheduling Environment (Aspen) and the Extensible Universal Remote Operations Planning Architecture (Europa) Nasa introduced two frameworks for solving scheduling and 13

25 Chapter 2. Mission Operation Platform and Planning Framework planning problems. Aspen was developed by the Jet Propulsion Laboratory under contract with Nasa and provides automation of planning and scheduling and plan optimisation tailored for space operations. It has proven its functionality in multiple use cases like the automated generation of tracking plans for the Deep Space Terminal of Nasa, automated command generation for rovers and more. Aspen uses activities to model the domain constraints, rules and components described in the dedicated Aspen Modelling Language (Aml), very similar to the Ddl of Apsi. The solving process of Aspen can be described as a process of finding plan conflicts where domain constraints are violated and repairing them by introducing new activities or manipulating existing activities via modifying their duration or moving them on their timelines. The process of identifying conflicts and repairing them, is repeated until no further conflicts can be detected. For further information on Aspen and its additional use cases see [11]. In contrast to Aspen, Europa is an open source project of Nasa and is publicly available 2 under Nasa s Open Source Agreement (Nosa). Like Apsi, Europa is a timeline- and constraint-based software framework which can be easily extended to implement planning and solving tools. Planning and scheduling problems are modelled in the New Domain Definition Language (Nddl), also very similar to Apsi s Ddl. For the problem solving itself, the framework provides multiple engines, databases and modules which allow reasoning and problem solving functionalities. Furthermore, Europa provides a wide variety of functions for plan visualisation and functions to support the constraint modelling which can be used with the eclipse development environment. Practical applications of the framework are the on-board planning on mobile robots or the support of the Deep Space One mission, for example.[12] Apsi is Esa s approach to establish intelligent, automated planning and scheduling successfully in satellite mission operations

26 Chapter 3. Mission Planning and Scheduling Constraints and Requirements During mission planning and scheduling, certain properties and constraints need to be considered. The process is supported by models describing properties and physical subsystems involved in mission planning. Additionally, it is necessary to consider requirements for the development of the scheduling tool, to ensure a seamless integration and usability of the tool in the future planning process Scheduling Goals The planning and scheduling process of the Cluster mission is driven by different factors with diverging priorities. As already mentioned, the most important factor of the ground station scheduling is the avoidance of an overflow and therefore an overwriting of the Ssr data. Depending on the data production rate of the scientific instruments, ground station passes need to be allocated more frequently in periods of high data production rate and less frequently in no science periods. The success of the mission is strongly related to the provided scientific data. Therefore, a maximised data return 1 is desirable. To achieve this goal, the produced ground station plans should also be robust to the unplanned loss of ground station passes and therefore tracking hours during a planning period. The loss of tracking hours can be caused by unpredictable malfunction of the spacecraft or the ground station, so called anomalies. Satellite launches require short-term booking of ground stations to support the launch and early orbit phase of a mission which results in a cancellation of all bookings on certain ground stations (mostly Kourou in case of a satellite launch from French Guiana). A further cause for loosing tracking hours can be imposed by a natural phenomenon of the ionosphere. It causes fluctuations of the Automatic Gain Control (Agc) and a bad signal-to-noise ratio which results in the loss of Tm (cf ). Furthermore, to ensure the operability of the spacecraft and avoid safe modes, the on-board time-tagged command buffer needs to be filled with enough commands to operate the spacecraft until the next ground station communication. (The constraints resulting from this goal are specified in ) 1 Data return is the amount of produced data which is downlinked to Earth. A data return of 100% would mean that all produced data could be downloaded. A smaller data return means that some scientific data has been lost permanently. 15

27 Chapter 3. Mission Planning and Scheduling Constraints and Requirements Besides from downloading all produced data, the overall station plan shall ideally maximise the average yearly (or monthly) data volume 2 while the costs for ground station usage should stay the same or be even reduced. This has the benefit, that savings in tracking hours during the year can be converted to more tracking hours at the end of the year and therefore an increase of the overall data volume Scheduling Properties Before talking about the scheduling itself, it is necessary to introduce the scheduling properties of the Cluster mission. The Fct receives multiple input files which need to be considered. Passes can be distinguished by their different types, describing the kind of properties of the pass and the conducted operations. Furthermore, the process of planning is divided into different phases and is following a strict periodicity Inputs Cluster scheduling is based on the following inputs which are imported and stored in the MySQL database of ClusterWeb or generated dynamically if required. Ground Station Visibility: Ground station visibilities are provided by Fd. Visibility times are supplied in form of Short Term Event Files and Long Term Event Files (Stef and Ltef). A ground station visibility starts when the pointing of the antenna is above an elevation of 5 degree. Below that threshold no communication link can be established due to bad signal caused by the Earth s atmosphere. Orbital Events: Similar to the ground station visibilities, orbital events are specified in the Stef and Ltef provided by Fd. Important orbital events are: perigee and apogee crossing, start of orbit (denoted by perigee crossing), eclipses and certain spacecraft altitudes (see ). ESTRACK Schedule: Estrack provides Cluster with a schedule of initial ground station passes and the booking of ground stations by other missions or maintenance activities. These informations are provided in form of a PlanView file. Schedule of Science Modes: Jsoc provides Cluster with a science schedule which inherits the different Tda modes, so called Observation Request files (Obrq). Spacecraft Commands: Commands for the spacecraft are produced by the Mission Planning System (Mps) and provided as Detailed Scheduled Files (Dsf). The commands are generated by combining the available Tda information from the Obrq, antenna information from the Stef and the pass information from ClusterWeb. 2 Data volume is the amount of scientific data produced in one orbit. 100% of data volume would correspond to an entire orbit in nominal science mode (Tda4, see ). 16

28 3.2. Scheduling Properties DSN Schedule: Until summer 2015, Nasa supported the Cluster mission by providing pass opportunities over their Dsn stations. Sporadic support might be still provided in case of emergencies. WBD Schedule: The schedule for Wide Band Data (Wbd, scientific instrumet) passes (which should be coherent with Tda8 sequences) is retrieved from the Jsoc web page. Special Payload Schedule: on and off times for certain payloads are directly coordinated with the principle investigators responsible for the payload. Link Budget: Based on slant range and elevation provided by Fd, the link budget for ground station visibilities can be computed. This means, a ground station visibility does not necessarily have a link budget with a signal-to-noise ratio good enough to allow a downlink from the spacecraft (for further information on the model of the link budget, see 3.4.2). SSR Fill Level: During scheduling, the Ssr fill level has always to be considered. It is based on the Ssr fill level model implemented in ClusterWeb under the consideration of the Tda modes and Cluster ground station passes (the model of the Ssr fill level is explained in more detail in 3.4.1). Special Operations: Special operations are for example manoeuvres or eclipses. In the context of these events, special activities are required during passes. All these inputs have to be considered during the process of planning and scheduling. Besides from the link budget and the Ssr fill level, all information is available in the ClusterWeb database. The Ssr fill level and the link budget are calculated dynamically for the requested time frame. ClusterWeb provides functions which implement the appropriate models for this Pass Types In order to describe the kind of operations which are conducted during a pass, certain pass types are defined. It is also possible to classify one pass with multiple types at the same time. In spring/summer 2015 a new type of pass operations has been introduced, called Multiple-Spacecraft Per Aperture (Mspa), where two spacecraft are communicating with one ground station at the same time (for a detailed explanation, see Appendix B). Routine (TM, TC and Ranging): This describes a routine pass with Tm dump, Tc uplink and ranging enabled. Ranging is necessary for Fd to be able to determine the spacecraft position in orbit. As a consequence of the low power budget, the Hpa is operated in Lpm during routine passes. This kind of pass is the most used pass type. 17

29 Chapter 3. Mission Planning and Scheduling Constraints and Requirements Routine (No Ranging): This pass type is similar to the pass type above, except that the ranging transponder is switched off. A transmitted ranging signal has a negative influence on the signal-to-noise ratio. Passes with a very marginal signal strength can be classified as no ranging passes, to give the data dump a priority over ranging activities. HPA Power Sharing: Hpa power sharing passes allow an enabled signal amplifier to conduct passes over ground station visibilities with a very bad signal-to-noise ratio. This is for example the case when the spacecraft is close to apogee. To be able to enable the High Power Mode (Hpm) of the Hpa, other subsystems need to be switched off to free some power. Therefore, two science instruments are temporarily disabled. Power sharing passes usually allow a downlink in Hbr. Dump-Only: Passes which allow no Tc uplink but only Tm dump are classified as dump-only passes. MSPA Primary Spacecraft: The primary Mspa spacecraft is connected to chain 1 of the ground station and is therefore able send Tm data to ground and is at the same time able to receive Tc from Earth. It can be commanded like it is the case during a routine pass. MSPA Secondary Spacecraft: The secondary Mspa spacecraft is connected to the second chain of the ground station. This means that only Tm dump is possible but no commanding of the spacecraft, similar to a dump-only pass. Eclipse Switch-OFF: As the batteries have been declared as non-operational on all spacecraft and the solar panels are not able to provide power due to missing sunlight and age related degradation, the satellites need to be switched off in a controlled way before entering an eclipse. At the end of the pass, the Ssr should be emptied completely as the remaining data can not be reproduced and is lost after the eclipse. Eclipse Recovery: After an eclipse, the spacecraft need to be recovered and switched on again. The overall health of the spacecraft is checked and payloads are enabled and patched to bring them back to an operational status. Manoeuvre Loading: Before each manoeuvre, a pass for uplinking the corresponding Tc to the spacecraft is picked. It is usually selected in a way that if the communication link fails and an upload was not possible, enough time for a second pass is available. Besides from the Tc uplink which must be guaranteed, this pass type is similar to a routine pass. Manoeuvre Verification: Manoeuvre verification passes can either take place during the manoeuvre or afterwards. If the manoeuvre is critical, a live observation of the Tm data is desirable to be able to intervene immediately if necessary. Especially attitude manoeuvres can be critical as a shadowing of the solar panels by the booms with scientific instruments attached needs to be avoided. During passes of this type, ranging has a priority over Ssr dump. In case of marginal signal-to-noise ratio the Ssr is put into record mode and the dump is paused. 18

30 3.3. Constraints Periodicity Ground station planning and scheduling is an activity which needs to be conducted on a weekly basis. Planning actions and the release of plans are grouped into planning periods which usually span about a week and start on Friday. Planning is done at least two weeks in advance until the end of the provided plan of Estrack. The two weeks directly following the time of planning are reserved for the generation of the final plan and therefore frozen Constraints In order to operate the spacecraft without problem and to be able to conduct ground station passes, the following requirements have to be considered during the process of Cluster scheduling. They are grouped in constraints imposed by ground station operations, driven by science, operational constraints and finally restraints enforced by the orbit dynamics Ground Station Constraints These con- Firstly, constraints on the ground station side have to be considered. straints are imposed by Estrack or Nasa s Dsn Availability A ground station must be visible and should not be booked by any other activity in order to be able to book a Cluster ground station pass. Additionally, the signal strength must be sufficient to be able to establish a stable communication link between the spacecraft and the ground station (see also link budget in 3.4.2) Configuration Activities Before the actual begin of tracking (Aos), a ground station configuration activity of 45 min has to be considered. During this time, the ground station must be available and should not be booked by any other activity. After the end of tracking (Los), a ground station post-pass activity of 15 min has to be considered. Similar to the pre-pass activity, no other activity should be booked during this time (cf. Figure 3.1). The ground station must not be visible during configuration activities. When two consecutive Cluster passes are scheduled on the same ground station, the time accounting for the post- and pre-pass activities between the passes can be reduced to exactly 10 min. This is the time required by the ground station to change between the different carrier frequencies of the spacecraft. Can this 10 min interval not be satisfied, a configuration time of at least 1 h (15 min post-pass and 45 min pre-pass activities) has to be considered (see Figure 3.2). 19

31 Chapter 3. Mission Planning and Scheduling Constraints and Requirements Aos Los Pass 45 min 15 min Fig. 3.1.: Ground station configuration activity constraints. Aos Los Aos Los Pass 1 Pass 2 45 min 10 min or 60 min 15 min Fig. 3.2.: Configuration activity constraints for two consecutive Cluster passes over the same ground station Downlink-only Passes From 2016 on, passes booked on New Norcia (Nno) foresee downlink-only. means that no commanding and ranging of the spacecraft will be possible. This Deep Space Network Passes Even though the support of Nasa s Dsn for the Cluster mission ended in summer 2015, support in case of emergencies is still possible. The schedule for Dsn passes is provided by Nasa. The start, end and duration of the passes is fixed and can not be changed. A re-assignment of a Dsn pass to a different spacecraft is possible. Dsn passes can not be conducted during Tda6 periods, with an exception for Tda6 burst-mode 3 intervals (see ) where the data can be stored in the Ssr Science Driven Constraints The operation and commanding of the scientific instruments has a significant influence on ground station scheduling and planning. This has mostly technical reasons of the satellite s subsystems Science Modes The satellite s scientific operations are defined by the Telemetry Data Acquisition (Tda) modes. Depending on the Tda mode, the data production rate and the type of recorded data differs. Overall eleven different Tda modes are defined in the On- Board Data Handling (Obdh) system. The four most relevant Tda modes for pass 20

32 3.3. Constraints planning are listed and explained below. The colours correspond to the background colour of the spacecraft timeline in the passes display of ClusterWeb (cf. Figure 2.1). TDA 2 (grey): A Tda mode 2 is represented as grey background colouring. During a science mode 2, no scientific measurements and observations are done. This means that the Ssr is only recording housekeeping data of the platform and the different subsystems. Tda2 is the mode with the flattest slope as only one housekeeping frame is recorded per format. TDA 4 (light yellow): Tda mode 4 is the nominal science mode and is depicted by a light yellow background of the timeline. During a Tda 4, one housekeeping frame and ten nominal science data frames are stored. TDA 6 (orange): Tda mode 6 is also called burst mode. In this science mode the data production rate is increased and leads to a Ssr fill level which is rising significantly faster than during nominal science mode. A Tda6 produces one housekeeping frame and 62 burst science data frames. For comparison, a Tda6 generates more than six times the amount of science data of a Tda4. Additionally to the normal Tda6, a so called Tda6 burst-mode 3 exists which lasts exactly 6 minutes. TDA 8 (light blue): With one housekeeping frame and ten nominal science data frames is the rate of recorded data during a Tda8 the same as during a Tda4. The difference to a Tda4 is that Wbd is downlinked to ground stations in the Czech Republic simultaneously to the recording of nominal science data. The downlink of this data is not the responsibility of Esa, but it has the implication that during science mode 8 no passes can be conducted by Esoc (also see scheduling constraints in subsection ). Cluster has begun to fully automate passes. At Aos intense commanding of the spacecraft is done by the automation system on ground. To avoid any clash between this commanding and an ongoing science mode change, Tda changes within Aos and Aos + 15 min are forbidden (see Figure 3.3). To avoid interferences of the commanding of the spacecraft and the automation system (especially the commanding of a Tda6 burst-mode 3) at the end of a pass, a safety margin of no Tda change between Los - 6 min and Los should be considered (cf. Figure 3.3). Aos Los Pass 15 min 6 min Fig. 3.3.: Tda mode change during pass constraint. 21

33 Chapter 3. Mission Planning and Scheduling Constraints and Requirements Wide Band Data When the spacecraft is in Tda8, no passes can be scheduled. Tda8 means that Wbd measurements are conducted and directly downlinked to ground stations in the Czech Republic. No passes can be scheduled as the spacecraft can only communicate with one ground station. Additionally, a margin of 1 min before a Wbd pass where no ground station pass can be scheduled must be considered. There is no constraint after the Wbd pass has ended (see Figure 3.4). Aos Los Aos Los Pass 1 Wbd Pass Pass 2 1 min no constraint Fig. 3.4.: Constraint for planning ground station passes concerning Wbd (Tda8) Cluster Ion Spectrometry Due to the degraded solar arrays, it is not possible anymore to operate the scientific instrument Cluster Ion Spectrometry (Cis) and the transmitter at the same time. Therefore, the transmitter needs to be switched off and no pass can be scheduled when Cis is switched on. To avoid overlapping, a margin of 2 min before and after Cis operations should be considered as displayed in Figure 3.5. Currently, only Clu1 is affected by this constraint. Aos Los Aos Los Clu1 Pass 1 Cis on Clu1 Pass 2 2 min 2 min Fig. 3.5.: Cis constraint on Clu Operational Constraints Also from the operational point of view, certain constraints need to be considered Pass Properties For cost efficiency reasons, scheduled passes should have a duration of at least 1 h. To avoid the overwriting of the on-board RAM Hk 3 the distance between two consecutive 3 A dedicated memory for housekeeping data with a capacity of 42 h of recording. 22

34 3.3. Constraints ground station passes should not be bigger than 40 hours (see Figure 3.6). Furthermore, two consecutive passes over different ground stations should have a separation of at least 10 min. This is necessary to avoid the clash of automated operations for each pass. Aos Los Aos Los Pass 1 Pass 2 min. 10 min and max. 40 h Fig. 3.6.: Maximum time of 40 h and minimum of 10 min between two consecutive passes of one spacecraft Power Sharing Passes Power sharing passes have been implemented to increase the returned data volume while tracking hours are kept constant or even decreased due to ground station shortage and limited tracking hour budget. During a power sharing pass, the scientific instruments of the Wave Experiment Consortium (Wec) and the Electron Drift Instrument (Edi) are switched off to free up some power which allows to operate the Hpa in Hpm. The agreement foresees only one power sharing pass per orbit. Furthermore, the power sharing passes shall have a duration of at least 1 h and shall not overlap Tda6 frames. A power sharing pass should only be booked if it is necessary to operate the Hpa in Hpm to achieve Hbr on the downlink. Additionally, commanding of Wec and Edi should not take place between Aos and Aos + 5 min and between Los and Los + 15 min as well as any Tda change as displayed in Figure 3.7. This ensures a proper boot up of the instruments after the power sharing pass. Until now, power sharing passes are only implemented for Clu3, with a possibility to extend this functionality to other spacecraft in the future. Aos Los Power Sharing Pass 5 min 15 min Fig. 3.7.: Command and Tda change constraint for power sharing passes. 23

35 Chapter 3. Mission Planning and Scheduling Constraints and Requirements Ranging To be able to determine the spacecraft position in orbit, ranging must be performed every second pass. Ranging activities require a Tc uplink Tele-Command Uplink The primary goal of Tc uplink is to fill the on-board Ttq so that enough commands are on the spacecraft to cover the second next pass Aos. It has to be considered that the maximum capacity of 2500 commands on-board of the spacecraft should not be exceeded and optimally a small margin for additional unplanned commands shall be available. If a coverage of the second next pass Aos can not be met, it must be possible to uplink enough commands to cover the whole next pass and the first visibility after that pass. This is important to not loose control of the spacecraft in case the next pass fails. If both constraints from above can not be met, at least the next pass has to be covered by the commands in the Ttq. This scenario is very unlikely as a pass should be conducted every 40 h due to the capacity of the RAM Hk (see ), but could appear in periods of satellite launches and a strongly limited ground station availability. Furthermore, it should be avoided to plan two consecutive passes without uplink possibilities (for example downlink-only and Mspa secondary passes) Multiple-Spacecraft Per Aperture For being able to schedule Mspa passes the requirements and constraints regarding the Angle Of Deviation (Aod) and the slant range have to be considered (see App. B for a detailed description of Mspa and its requirements). According to no two sequential Mspa secondary passes (dump-only) should be booked on a spacecraft. As displayed in Figure 3.8, the Aos sequence of the shadow (secondary) pass can start 5 min after the Aos sequence of the primary spacecraft soonest. The Los sequence of the shadow track has to be deployed at least 6 min before the Los sequence of the primary spacecraft. For now Tda changes during Mspa operation should be avoided as operational sequences and procedures have not been deployed yet Manoeuvres As already described in 3.2.2, the manoeuvre commands need to be uploaded to the spacecraft with a margin to the actual manoeuvre time to be able to upload the commands a second time, in case the uplink failed on the first trial. It should be able to mark the corresponding pass as Manoeuvre Loading pass which forbids the rescheduling of the pass by the planning tool. The same constraint is applicable for Manoeuvre Verification passes where the successful conduction of the manoeuvre is evaluated with the help of ranging and Doppler measurements. Due to the very limited available power provided by the solar panels, the overall temperature of the spacecraft in routine operation decreased significantly compared 24

36 3.3. Constraints Aos Los Prime Track Aos Los Shadow Track 5 min 6 min Fig. 3.8.: Constraints for Aos and Los of a Mspa secondary pass. to the beginning of mission and heaters for the pipework and thrusters are switched off permanently.[2] To guarantee a good performance of the thrusters and avoid clumping of the fuel in the pipelines, a pre-heating of the subsystems is required before the execution of a manoeuvre. To free up electrical power which can be invested in the operation of appropriate heaters, the Tm transmitter is switched off before a manoeuvre for the time of the pre-heating. This means, that no pass can be scheduled for the corresponding time frame. Currently, only Clu2 requires a pre-heating period of 3 h before a manoeuvre. It is very likely that with a further degradation of the solar arrays other spacecraft will follow Eclipses Eclipse operation is a very critical phase during the year. Due to the lack of operational batteries, the spacecraft need to be shut down before every eclipse and and configured for nominal operation after each eclipse. For this, dedicated Eclipse Switch-OFF and Eclipse Recovery passes have been implemented (see 3.2.2) which follow specific procedures. Similar to the manoeuvre dedicated passes, eclipse passes are scheduled manually by the Fct and should not be rescheduled by the scheduling tool. A further constraint regarding the switch-off passes is the requirement to empty the on-board Ssr completely until the end of the pass to avoid the loss of data. For periods between a switch-off and a recovery pass, no further passes should be scheduled Automatic Gain Control Fluctuation The Automatic Gain Control (Agc) is used to provide a unified signal amplitude to the receiver. Agc fluctuations are a phenomenon which can be observed on both the on-board receiver of the satellite (cf. Figure 3.9), as well as on the ground station receiver. Heavy fluctuations of the signal strength of up to 10 db result in the loss of Tm data up to the complete loss of communication link between spacecraft and 25

37 Chapter 3. Mission Planning and Scheduling Constraints and Requirements Fig. 3.9.: Agc fluctuations on a ground station pass of Clu4 over Msp on 12. September ground station. The source of the Agc fluctuations are disturbances in the Earth s ionosphere close to the geomagnetic equator. The Cluster mission is not the only mission which is affected by these disturbances.[13] From operational experiences of the Cluster Fct, it can be assumed that the phenomenon of Agc fluctuations is most likely a seasonal effect which occurs mainly during the European fall and winter season at late evening and night times. Especially the ground station in Maspalomas is affected by regular Agc fluctuations. Minor occurrences of the phenomenon can be observed on Vl2 and Kru. A consideration of this constraint is relevant to avoid the loss of ground station passes and the short-term scheduling of new passes Orbital Constraints The orbit and the effects on the spacecraft depending on its position in the orbit imposes some constraints on the operation and scheduling of ground station passes Perigee Transmitter Off Due to regulations of the International Telecommunications Union, the spacecraft s transmitter has to be switched off in altitudes below 6000 km. No passes shall be scheduled during these periods Perigee Power Drop The radiation which was accumulated during the passages through the inner van Allen belt from 2008 until 2012 changed the thermal properties of the solar cells. As 26

38 3.4. Models a consequence, an increasing cell temperature results in a reduced provided power by the solar panels. This can cause a power drop of up to 30 W which was observed in August 2012 with a raised cell temperature from 6 C to 11 C and a perigee altitude of about 3700 km. The increased cell temperature originates from the reflection of the sunlight on the Earth s albedo.[2][3] Therefore, a careful planning and observation of the power budget is required. Due to a decreasing perigee height in the future, it may require certain periods around perigee where the transmitter needs to be switched off to avoid a main bus under-voltage when power drops occur. The depth of a power drop may differ from spacecraft to spacecraft, therefore it is necessary to be able to define a no pass time frame for each spacecraft individually Models For modelling the Ssr and link budget in ClusterWeb, the following models have been deployed Solid State Recorder As the Ssr fill level is the major driving factor of pass scheduling, an accurate model for the evolution of the fill level is necessary. Table 3.1 gives an overview of how the Ssr fill level changes according to the different Tda modes outside of a pass. During a ground station pass, live Tm and Ssr data is dumped from the spacecraft. This means, that these two types of data share the bandwidth of bps in Lbr (Tda7L) and bps in Hbr (Tda7H). Therefore the Ssr fill level is effectively reduced to a rate of bps in Lbr and bps in Hbr. It must also be considered that during a Tda6 no Ssr dump is possible but only the downlink of the live Tm. Especially a Tda6 pass during a Hbr visibility would result in a waste of downlink bandwidth. Tda mode L 7H 8 Production rate [bps] Downlink rate [bps] SSR dump rate [bps] Tab. 3.1.: Ssr data production rate depending on the Tda mode. Furthermore, it has to be considered that the Ssr dump does not start and stop exactly at pass start and end, respectively. Configuration activities of the spacecraft take 9 min after Aos and 1 min before Los where no dump is possible (cf. Fig. 3.10) Link Budget Depending on the link budget, passes can be conducted in Lbr or Hbr. The following link budget model is implemented in ClusterWeb and helps the Fct to identify good 27

39 Chapter 3. Mission Planning and Scheduling Constraints and Requirements Aos Los Pass 9 min Ssr dump 1 min Fig : Ssr dump margins for spacecraft configuration after Aos and before Los. pass opportunities (cf. link budget graph in Figure 2.2). Where: Es No = EIRP L F S L AT M L P OL L RNG L DEM k + G T L RS EIRP : Effective Isotropic Radiated Power [dbm] L F S : Free space loss [db] L AT M : Loss due to atmospheric absorption [db] L P OL : Polarisation loss [db] L RNG : Ranging loss [db] L DEM : Demodulation loss [db] k: Boltzmann s constant [dbw/k khz] G: Ground station antenna gain [dbi] T : Ground station thermal noise [db] L RS : Symbol rate loss [db] The values for the figures above differ between the different ground stations and spacecraft. For Mspa operations a pointing loss L P T has to be considered additionally. It is also worth noting that ranging activities have a negative influence on the link budget Scheduling Tool Requirements For an optimal usage and integration of the tool in the current workflow and operational environment, certain constraints and requirements have to be considered during the design and implementation of the tool. 28

40 3.5. Scheduling Tool Requirements Compatibility For a better usability, the scheduling tool shall integrate seamlessly in the current scheduling workflow which consists of the actual scheduling activities performed in ClusterWeb and Mps. The amount of manual interactions should be minimised and the overall planning process should be kept as simple as possible. As mission operation underlies a constant change of constraints, it might be necessary to implement new models of the scheduling constraints and properties. The models should be easily exchangeable. The plans generated by the tool should be made available to ClusterWeb which allows the Fct to use the existing interfaces to Mps and scheduling office Configurability It shall be possible to configure the start and end time of the period in which the automated scheduling will be performed by the tool. Certain constraints have a small flexibility which should be configurable by the user. In times of reduced ground station availability it is for example acceptable to relax the constraint of having a maximum separation of 40 h between two consecutive ground station passes. Additionally, certain constraints are currently only applicable for individual spacecraft. Nevertheless, an option to consider the same constraint for other spacecraft should be available to anticipate the necessity of the same constraint in the future Quality Measurement The tool shall be able to provide the operator with information about the produced plans to enable the user to judge on the quality of the plans. Suitable criteria are for example the overall tracking hours and the returned data volume per tracking hour. 29

41 Chapter 4. Analysis of Goals, Requirements and Resources The goals, requirements and resources of the ground station scheduling need to be analysed in terms of their importance for the design and implementation, to be able to anticipate delays and problems during the development process. Furthermore, it is analysed how the constraints and initial configuration of the spacecraft should be provided to Apsi and how to convert the results of the planning process back to a format which can be interfaced by ClusterWeb. It is also necessary to analyse the Cluster scheduling constraints to see which information can be pre-processed and what constraints need to be taken into account during the solving process. It must be evaluated how the Gui for the tool should be defined to enable the user to judge on the quality of the produced plans Scheduling Goals The main driving factor which dictates the plan generation is the Ssr fill level. Furthermore, it is important to generate plans robust to the loss of tracking hours. An increasing robustness of a plan can be achieved by decreasing the hours between two consecutive passes and reducing the duration of single passes while the overall number of passes increases. The disadvantage of increasing the robustness in this way is the rising number of configuration hours as the number of passes is directly proportional to it (one configuration hour per pass). As an example, a plan with two Lbr ground station passes with a duration of 5 h each is considered for one spacecraft in a fixed time interval (as shown in Figure 4.1a). In this case Estrack charges 12 h tracking time, 10 h for the tracking itself and 1 h of configuration time for each pass. This plan is not very robust, the loss of one pass has a rather big impact on the evolution of the (increasing) Ssr fill level and would probably require the short-term booking of an additional pass. To increase the robustness, the plan is changed to five Lbr passes with a duration of 2 h each (see Figure 4.1b). The amount of 10 h dump time and therefore the amount of returned data stays the same. But, in case one pass fails, only 2 h of dump time are lost. On the other hand, the costs for the more robust plan have increased significantly by 25% as Estrack charges now for 5 instead of 2 tracking hours. A more robust plan can only be achieved by increasing the number of passes and therefore increasing the overall costs for tracking hours. The preference of a cheaper 30

42 4.2. Capabilities of APSI P1 P2 P1 P2 P3 P4 P5 (a) Two passes 5 h each. (b) Five passes 2 h each. Fig. 4.1.: Comparison of plans with different robustness and the effect of a lost pass on the Ssr fill level. or more robust plan should be balanced by the user depending on the circumstances of the individual planning period, like the average Ssr fill level or a high station availability. This requirement is directly followed by ensuring that the Ttq is filled with enough commands to operate the spacecraft until the next pass. The problem here is the release of the schedule with the exact Tc sequences two weeks before execution. The reason for this is, that the command generation is dependent on the pass allocation which requires the final plan and a freezing of all planning activities in this interval (see properties in 3.2.3). Usually, it can be assumed that if the time between two consecutive passes is not exceeding the 40 h imposed by the RAM Hk constraint (cf ), the number of commands on-board of the spacecraft should be sufficient to cover at least the next Aos. To ensure a safe operation of the spacecraft, it is inevitable to do manual checks by the on-call engineer or the spacecraft controller that this constraint is always fulfilled. At the current stage, this is the only way to handle this constraint as a complex model of the command generation would be necessary within Apsi. Nevertheless, the constraint is further discussed in for future development of the tool Capabilities of APSI Apsi provides a variety of components, resources and other representations for domains and scheduling problems. Furthermore, different interfaces to and from Apsi exist. A careful analysis of these capabilities should point out how to utilise them to achieve the best result for the scheduling tool Interfaces to and from APSI As explained in 2.2.2, Apsi comes with three different possibilities to make the problem domain and the problem itself available to the framework (Java code, XML files, Ddl/Pdl files). Each of the presented methods comes with assets and drawbacks. 31

43 Chapter 4. Analysis of Goals, Requirements and Resources An implementation of the domain and problem model in Java has the benefit that it requires a minimum manual interaction and execution steps until a ground station plan is generated. A simple start of the scheduling tool and the definition of the desired planning period, plus specifying necessary constraints is sufficient to produce multiple solutions from which a suitable pass schedule can be selected. Finally, the plan needs to be exported from the tool to a predefined file format and imported to ClusterWeb through a newly developed import function. Nevertheless, the following disadvantages outweigh the presented advantage by far. The biggest drawback of this technique is that it is very static and not flexible. Firstly, satellite mission operation underlies permanent changes which would require an adaptation of the tool s source code every time one of the constraints changes, followed by a re-compilation. Usually, the source code of such tools can get very extensive and the maintenance of the domain requires a good overview over the full source code. Furthermore, the scheduling tool must be able to fetch all necessary information (ground station visibilities, bookings, etc.) from the ClusterWeb database, which requires a direct connection to the database. This has the implication that the tool must be deployed somewhere in the local network of Esoc where a connection to the ClusterWeb server is available or a VPN connection must be established. Providing Apsi the domain and problem as a XML file has the benefit that the interface between ClusterWeb and its database and the scheduling tool is very clean. This means, the tool can be implemented independently from how the domain is defined. Changes of the scheduling constraints would only require an adaptation of the XML file without changing the tool s source code. This is especially very beneficial for the maintainability of the domain. Furthermore, it is easily possible to test different scenarios with diverging domains. The biggest drawback of this method is the fact that XML is a very verbose language to express multiple properties of a system. This results in a bad readability for a human operator and a cumbersome process of editing the XML file. This becomes clear by looking at the number of necessary data sets and by estimating the number of lines an XML file containing this information would reach. In the case of Cluster, the initially required data for ground station visibilities, etc. from the ClusterWeb database can easily imply more than 1000 data sets per week. A minor drawback is that the manual interaction is increased by the production of a XML file containing this initial information for the desired planning period. This requires an extra interface in ClusterWeb where the start and end time of the XML can be specified and the necessary data is automatically fetched from the database and converted into a XML file format. This approach has no implication on where the tool is deployed and how it is integrated. The last option is to utilise the Ddl and Pdl file formats which where designed to ease the process of defining a problem domain and the problem itself for Apsi. In principle, this approach is very similar to the XML approach. The general problem domain is specified in the Ddl file and the more specific problem (which changes depending on the start and end time of the to be planned period) is specified in the Pdl file. The distinct advantage of the Ddl/Pdl files compared to XML files is that the domain and problem definition languages are tailored for the description of this kind of application. This enhances the editability of the Ddl and provides the user 32

44 4.2. Capabilities of APSI a much better overview of the domain. For these reasons, it was decided to use the approach of creating Ddl and Pdl files to interface the Apsi framework from ClusterWeb. When a solution is found, it is necessary to make that plan available to Cluster- Web. For this, Apsi provides the functionality to create XML files which contain a selected solution. Another option of providing the generated plan to ClusterWeb is to insert the data directly in the ClusterWeb database by using Java functions and MySQL calls from the tool s source code. The advantages and disadvantages of these methods are very similar to the ones mentioned above for the other direction. Using function calls to the ClusterWeb database in the tool source code would reduce the manual interaction steps to a minimum, but the maintainability of the interface is rather cumbersome. On the other hand, going for the approach of creating XML files guarantees a much cleaner interface between the two platforms and even the production of multiple plans can be achieved. Additionally, ClusterWeb is producing XML based files to provide the pass plans to Mps, called PlanCWeb. The same file format could also be utilised for the interface between Apsi and ClusterWeb. If no further adjustment of the plan was necessary, the XML file generated by the scheduling tool can even be supplied directly to Mps. Going for this approach requires an interface in ClusterWeb which is capable of interpreting the file format and importing the passes to the ClusterWeb database Available Planner Apsi is equipped with a number of different solvers whereas each solver has a different functionality. For example, there exist solvers to complete timelines and solvers responsible for modifying already existing plans. As the problems occurring during the solving of the Cluster scenario might not be solvable by only one solver, a recently introduced planner (Plasma, PLAn Space Multi-solver Application) is tailored and deployed. Plasma is a domain independent planner and solver consisting of several solvers which are activated if a flaw is detected. The application then runs its listed solvers and tries to solve the problem.[14] A tailoring of Plasma is done by Hso-Osa and is not in the scope of this thesis Domain and Problem Modelling As discussed before, scheduling domains and their problems are modelled using the Ddl and Pdl file format, respectively. The constraint-based languages are designed to describe timeline-based planning and scheduling problems. The modelling language is defined by timelines, components and data which can be inherited by a component.[8][9] Each timeline describes the evolution of one component type. Existing and relevant component types for Cluster scheduling are Ground State Variables, State Variables and Consumable Resources. Additionally, it was necessary to introduce the new component type Reservoir Resource. As already pointed out in section 2.2.1, state variables can only inherit one distinct 33

45 Chapter 4. Analysis of Goals, Requirements and Resources state at a time. The difference between a ground state variable and a state variable is that a state variable is capable of containing parameters whereas a ground state variable is not. Parameters allow a further reasoning on state variables and are necessary to describe the state more detailed. Data types of relevance for parameters are Enumerations and Objects. Enumerations have certain predefined values which allow reasoning on the parameter value. Objects basically represent strings which do not allow any reasoning and only serve the transfer of information to the end user. The information is spread among different timelines. Components are used by these languages to describe certain events on the timelines. To be able to reason on the information on different timelines, synchronisations exist. They allow to specify how components on two different timelines depend on each other. Figure 4.2 displays exemplary two components on two timelines with a synchronisation between the timelines. Tl1 Component(Data) Synchronised Comp. synchronisation t Tl2 Component(Data) t Fig. 4.2.: Two timelines with a synchronised component. For modelling resources, Apsi provides the consumable resources on the one hand and the reservoir resource on the other. As presented in 2.2.1, the consumable resource is a resource which produces or consumes a certain value at an instant of time. Considering a certain very small resolution, the representation of a constant linear production and consumption is also possible. For a better usability and more flexibility, it has been decided to introduce another resource called reservoir resource. This resource allows to define constant production rates by defining the steepness of the slope (cf. Figure 4.3). Similar to the consumable resource an upper and lower bound, ub and lb, needs to be defined for the resource (see also [14]). prod. con. ub o t lb Fig. 4.3.: Representation of the reservoir resource. A detailed analysis of the constraints and problems in 4.3 should point out how the constraints can be modelled by utilising the presented components, data types, resources and synchronisations among them. 34

46 4.3. Cluster-II Planning Constraints Furthermore, it has to be analysed if a constraint is of general nature or a more specific constraint which changes according to the defined time interval of scheduling. Therefore, it has to be distinguished between constraints modelled in the Ddl file and constraints specified in the Pdl file. In general, it can be said that Ddl files describe the constraints, their properties, the number of timelines and define which components are allocated on which timeline. In other words, the domain gives the frame of the system which should be described. The Pdl files define specific problems and create activities (based on the specified components) on the timelines. An activity which is specified in the Pdl is for example the definition of perigee crossing, a listing of external ground station bookings, the specification of visibilities and so on. The Pdl fills, so to say, the timelines with initial conditions and events of the system Cluster-II Planning Constraints As already pointed out in 4.2.3, the constraints and requirements presented in chapter 3 can be modelled in the Ddl file if they describe the overall system or modelled in the Pdl file if they describe a specific condition for the selected time frame of plan generation. The following categorises the constraints and gives a first analysis of which types of components and which timelines are necessary and how the timelines need to be synchronised between each other Domain Constraints Domain constraints are specified in the Ddl and are not supposed to be changed often. A manual adjustment of some requirements might be necessary from time to time, but not on a regular basis. These constraints are always applicable independent from the specified time interval for plan generation. The understanding of the planning and scheduling constraints is discussed and how they are supposed to be modelled as state variable, resource or any other component type. Furthermore, allowed transitions between different states need to be considered Minimum Pass Duration Passes should always have a duration of at least one hour. This constraint is always applicable for every pass and therefore needs to be modelled in the Ddl file. The state which describes a pass needs to have a specified minimum duration of 60 min Time Between Two Consecutive Passes Pass activities move flexibly on the timelines for each spacecraft and are not known in advance (except for certain fixed passes which cannot be moved). Therefore, the constraint to keep the maximum time between two consecutive passes of one spacecraft below 40 h, to avoid an overflow of the RAM Hk, needs to be modelled as a 35

47 Chapter 4. Analysis of Goals, Requirements and Resources restriction on the duration of a certain state variable. To respect commanding activities of the automation system, a minimum time of 10 min between two consecutive passes must be specified for the same state variable Ground Station Configuration Activities and Bookings Ground station activities for Aos, Los and reconfiguration between two different Cluster satellites must be modelled as states a ground station can inherit. These states must have a fixed duration of exactly 45 min for Aos, 15 min for Los and 10 min for the reconfiguration of the ground station between two consecutive passes. Transitions between the states must be specified according to the constraints and under consideration of the preceding and following ground station activities (external or cluster booking). A synchronisation to the passes timeline is necessary to identify periods of Cluster bookings and allocate the right ground station activity before and after a Cluster booking on the timeline of the appropriate ground station Science Mode Changes Every pass activity must fulfil the constraint of no science (Tda) change between Aos and Aos + 15 min and Los - 6 min and Los. As Aos and Los are dynamically allocated on a timeline, this constraint must be modelled as a synchronisation between a pass activity and a timeline containing the Tda modes Ground Station Bookings Cluster ground station bookings must exist as synchronised components from the passes timeline of each spacecraft. This should avoid double booking of the same ground station by two different Cluster spacecraft Link Budget Depending on the chosen Hpa mode, the appropriate downlink rates for a ground station pass need to selected. This requires a synchronisation to the link budget timeline under the consideration of the spacecraft configuration Multiple-Spacecraft Per Aperture Booking a Mspa secondary pass requires to synchronise its Aos and Los times with the primary pass to satisfy the margin of 5 min and 6 min, respectively. Additionally, a synchronisation to the Tda timeline is required to avoid the planning of Mspa passes during Tda changes. This means, Mspa passes can only be booked within one science mode. 36

48 4.3. Cluster-II Planning Constraints On-Board Time Tag Schedule The most suitable resource for modelling the on-board time tag queue in the Ddl is the consumable resource. The resource is getting filled/produced after Aos of a ground station pass, whereas a Tc execution consumes one resource unit. The consumption of payload Tcs requires a synchronisation to a timeline where the commands of the scientific instruments are allocated. Commands required for pass activities and for the operation of the platform would require a rather complex model within Apsi and a dynamic generation of these commands depending on the allocation of the passes by the tool. Therefore this constraint is not followed up further and is a candidate for future work SSR Fill Level For modelling the spacecraft s Ssr fill level, a new component type has been introduced to Apsi. The reservoir resource is able to model a constant resource production and consumption per time unit. According to the Tda modes and dump rates during a pass, the fill level increases or decreases, respectively. This requires a synchronisation to the Tda mode timeline and a synchronisation to passes and their dump rates Power Sharing Passes Power sharing passes have to respect the constraint of no Tda change between Aos and Aos + 5 min and Los and Los + 15 min which requires a synchronisation to the Tda mode timeline. To avoid a commanding of Wec and Edi at these times, a synchronisation to the Ttq timeline has to be done. Due to the reasons explained in 4.1, this timeline will most probably be empty which makes the consideration of this constraint neglectable for now Automatic Gain Control Fluctuations So far, no precise model exists for when and where Agc fluctuations occur. Totally avoiding the scheduling of passes over Msp, Vl2 or Kru during evening and night hours during the fall and winter season would result in too few ground station opportunities to be able to dump all Ssr data. Furthermore, this does still not ensure that Agc fluctuations are avoided. Until no further knowledge about this phenomenon is gathered or the occurrences can be estimated more precisely, this constraint won t be considered during the ground station scheduling for now Scenario Constraints Constraints which are dependent on the specified time interval of scheduling are provided to Apsi in form of a Pdl file. This file fills the frame which is given by the Ddl and states the initial conditions of the desired scenario. The Pdl can also be 37

49 Chapter 4. Analysis of Goals, Requirements and Resources seen as a snapshot of the ClusterWeb database tailored to the needs of scheduling and written in a language that can be interpreted by Apsi. A tailoring of the data can be achieved by pre-processing the information before exporting it to the Pdl file Ground Station Availability Ground station visibilities and the link budget change dynamically depending on the specified time interval for which a ground station pass plan should be generated. Ground station visibilities need to be modelled as state variables on timelines for each individual ground station. Depending on the slant range and elevation of the spacecraft, the link budget changes. This means, even during a visibility it might not be possible to establish a stable communication link to the satellite. Apsi should only be provided with actual ground station availabilities from which it can choose, neglecting visibilities or periods during a visibility where the link budget is too low. Availabilities can be divided in Lbr and Hbr availabilities and those having a change from low to high or vice versa. This information can be pre-processed by extracting the link budget for the ground stations and spacecraft from ClusterWeb and allows an allocation of the corresponding bit rates on a timeline for each individual ground station. The actual bit rate can be specified as a parameter value of a state describing a downlink availability. This allows Apsi an easy reasoning on the link budget of a ground station availability. The link budget changes if the Hpa is allowed to go to Hpm for a certain spacecraft. Therefore, it is necessary to have the availability information for both spacecraft configurations on different timelines Power Sharing Passes In fact, only power sharing passes utilise the availabilities given on the Hpm timeline of a spacecraft. The constraint for this type of pass imposes that it should not be booked if Hbr is already available in Lpm. This means, that the content of this timeline should ideally be pre-processed in a way that only power sharing opportunities are given where no Hbr is possible in Lpm Downlink-only Passes If a ground station is able to uplink Tc or not, should be identifiable by the ground station availability. This property should be definable for each ground station individually and can be modelled as a parameter value of the availability Perigee Transmitter Off The orbit and therefore the spacecraft position is already known beforehand which allows to implement a no pass possible frame where the spacecraft altitude is below 6000 km and requires a switch off of the transmitter. This frame can be preprocessed by querying the database for the necessary information provided by Fd. The frames need to be allocated on a timeline to allow Apsi to reason on the times where no pass can be scheduled. 38

50 4.3. Cluster-II Planning Constraints Perigee Power Drop Also the perigee crossing times are available beforehand and can be retrieved from the ClusterWeb database. This allows to implement a no pass possible frame for each spacecraft individually. According to the specified margin, a frame should be allocated around every perigee crossing Science Modes The Tda mode schedule is known weeks in advance and differs from one planning period to another. The Tda modes can be derived from the sequences provided by Jsoc. They do not change and can be modelled as state variables for each mode. The Tda modes can be pre-processed and allocated on a timeline for the science mode of each spacecraft Deep Space Network Passes Even though the support of Dsn has officially ended, the constraints are implemented to be as flexible as possible and being ready for all eventualities. Dsn pass times are available in advance and can be fetched from the database. Dsn passes are imported to Apsi as a fixed event for one spacecraft. Fixed passes are events on the pass timeline which cannot be changed and have a predefined downlink rate, which is in the case of Dsn passes always Hbr. As the routine support of Dsn has ended and support is only given in rare cases of emergency, the request and assignment of a Dsn pass to another spacecraft must be done manually and is not supported by the scheduling tool Multiple-Spacecraft Per Aperture Depending on the slant range and the Angle Of Deviation (Aod) between a Cluster pair, Mspa opportunities might occur. The information about the slant range and Aod are stored in the ClusterWeb database and can be queried. By pre-processing the requirements during the generation of the Pdl, it is possible to detect opportunities and post them on dedicated timelines Orbit Events Necessary orbit events like the perigee crossing should be fetched from the database and allocated on a separate timeline. Other orbit events like apogee crossing which serve a more informational purpose can also be queried from the ClusterWeb database and posted on the orbital events timeline Instrument Constraints The times for Cis operation on Clu1 and Wbd passes for all spacecraft are stored in the database. These times can be queried and no pass possible frames allocated on the passes timeline of each spacecraft accordingly. It has to considered that the 39

51 Chapter 4. Analysis of Goals, Requirements and Resources frame needs to be extended by 2 min before and after Cis operation and 1 min before Wbd operation Manoeuvre Constraints Passes dedicated to manoeuvres can be identified by querying the passes table in the ClusterWeb database and checking the pass type. Passes of this kind should stay unchanged during the scheduling process. Manoeuvre passes should be posted as fixed passes on the passes timeline of the appropriate spacecraft. For each fixed pass the downlink rate has to be determined by checking the link budget for the pass. To optimise the process of reasoning on fixed passes, manoeuvre passes with different downlink rates are split into multiple fixed pass states whereas each state has only one fixed downlink rate. Additionally, no pass possible time frames respecting the pre-heating of the thrusters and the fuel pipelines have to be allocated on the passes timeline, if specified Eclipse Constraints Similar to manoeuvres, passes might be dedicated to eclipse operation. Eclipse passes are assigned to an eclipse in the eclipses table of the database. These passes should not be moved or rescheduled and serve the purpose of switching the spacecraft off before eclipse and recover it after an eclipse. In between these passes, no other ground station pass should be booked. This can be achieved by allocating a no pass possible frame between Los of the switch off pass and Aos of the recovery pass. Furthermore, it is necessary to advise Apsi to empty the Ssr completely before the spacecraft is switched off. This must be done by calling a certain function at the end of the switch off pass Post-Processing of Constraints Besides from posting general constraints in the Ddl file and pre-processing the ClusterWeb data before exporting it to the Pdl file, post-processing of found solutions can be done to introduce further constraints. A post-processing deletes the solutions from Apsi s plan database and does not present them to the user Ranging For a good orbit determination, it is necessary to do ranging activities at least every second consecutive ground station pass of a spacecraft, which requires uplink capabilities of the ground station. This means that no two consecutive passes over a ground station with dump-only capabilities should be booked. Furthermore, no two consecutive Mspa secondary passes should be booked on one spacecraft. Solutions where this constraint cannot be fulfilled, can be identified by postprocessing the passes timelines and deleting the plan from the list of available solutions. 40

52 4.4. User Interaction Power Sharing Pass Power sharing passes should not be scheduled during a Tda6. This can be identified by post-processing the passes timelines and comparing it with the Tda timeline of each spacecraft. Solutions not regarding this constraint can be removed from the list of possible solutions User Interaction As mission operations are constantly changing, the user should be able to modify certain settings and preconditions for different planning periods. For example, the possibility of power sharing passes might be extended to different spacecraft than Clu3 in the future. Or the necessity of pipeline and thruster pre-heating before manoeuvres might be extended to other spacecraft than only Clu2 in the upcoming years. To set these properties individually for each spacecraft, a user interaction when creating the initial Pdl file is required. As ClusterWeb is the platform where mission planning is mostly done on, the interaction with Apsi should be initiated from the planning section of the website. Therefore, an extra web page with the possibility to configure and execute the Pdl file generator is necessary. Once the initial problem is available for Apsi, the scheduling tool should start the solution process and present the user a certain amount of solutions. To enable the operator to identify the best solution, it is necessary to find a proper way to measure the quality of a solution (see 4.5). The solution shall be displayed in a way that the operator can judge on the applicability of the presented pass schedule for all four spacecraft. To stay consistent with the representation of scheduled passes in ClusterWeb, the display should be very similar to the one presented in Figure 2.1. A first mock-up of the scheduling tool Gui is displayed in Figure 4.4. The main problem here is to find an acceptable trade-off between not displaying data in order to keep the overview and leaving out important information. The operator must be able to analyse the solution on a rather big time scale of some weeks. If the user selects a suitable solution, a file bridging the interface from Apsi to ClusterWeb needs to be created and imported back to the ClusterWeb database as already discussed in Quality Measurement To be able to assess the quality of a plan, it is necessary to find appropriate criteria for it. The main criteria is to keep the costs low while fulfilling all constraints and especially reaching the goal to keep the Ssr fill level as low as possible. Costs are generated by ground station bookings of Cluster. This includes also the configuration time for each Cluster ground station booking (Aos and Los). Furthermore, the hours of Wec power sharing should be kept at a very minimum to allow as much science operation as possible. In general, it can be stated that a high volume of science return with a low number of tracking hours results in a good 41

53 Chapter 4. Analysis of Goals, Requirements and Resources Fig. 4.4.: Mock-up of the scheduling tool s Gui. cost efficiency. But it must be always considered that the robustness of the plan to the loss of ground station passes should be maximised. To be able to classify a plan according to these criteria, a good way to represent those values is needed. A first representation of the quality should be given directly after Apsi found a certain amount of solutions for the problem (see table in bottom pane of the mock-up in Fig This allows the operator to select the best schedule and use it for mission operation. 42

54 Chapter 5. Cluster-II Scheduling Tool This chapter describes how the tool is deployed and which interfaces and elements are needed. According to the analysis of the constraints and requirements for Cluster planning and scheduling, designs for the scheduling tool and the models are presented. Lastly, it is shown how the constraints, interfaces and the tool itself have been implemented Tool Deployment and Workflow Figure 5.1 shows the deployment of the tool in the mission planning workflow and what interfaces and files are required in the architecture to interact with the scheduling tool. The elements which needed to be implemented are marked by a light yellow background colour. These are the interfaces from and to Apsi as well as the interface in Apsi which produces the plan imported by ClusterWeb. The Ddl file containing the model of the constraints also needs to be designed. The workflow for creating ground station pass schedules with the help of the scheduling tool looks like the following: (1) The mission planning process is initiated by the scheduling office which is providing a first ground station schedule with some Cluster passes allocated. (2) As already mentioned, these passes mostly do not fulfil the scheduling constraints of the mission as the scheduling office has no access to Tda modes, instrument on/off times, Wbd passes and so on. The necessary data is provided by Jsoc and imported into the ClusterWeb database. (3) With the information available in the ClusterWeb database, the automated planning process can be started by converting the necessary data for the given time frame into the Pdl file format and provide it to the scheduling tool. (4) After starting the scheduling tool the Pdl file is imported and the solving process is started. A good solution needs to be identified and selected with the help of the provided Gui. (5) The selected solution is exported to the PlanCWeb file format by the scheduling tool. (6) The newly generated ground station plan is imported to the ClusterWeb database. All existing passes in the database, except for fixed passes dedicated to special operations (manoeuvres, eclipses and marked so), are deleted for the specified time range of the PlanCWeb file. (7) The scheduling office is informed about the new updates of the Cluster schedule. 43

55 Chapter 5. Cluster-II Scheduling Tool Sched. Office Jsoc (7) Updates (1) PlanView (2) Tda modes,... ClusterWeb.Ddl Scheduling Tool (3) Interface to Apsi.Pdl Apsi ClusterWeb Database (4) Gui (6) Interface from Apsi Plan CWeb (5) Interface to CWeb Plan CWeb (8) Mps Fig. 5.1.: Deployment of the scheduling tool in the workflow of the mission planning environment. Elements which were implemented are marked by a light yellow background colour. (8) If further manual adjustments of the ground station passes were necessary, a new PlanCWeb file is created by ClusterWeb. Otherwise, the PlanCWeb file produced by Apsi can be directly sent to Mps. The Mps then generates the set of commands for the spacecraft and creates the Ttq and the products required for automated spacecraft operation Design of the Domain Model After the constraint analysis of the Cluster scheduling problem, the model for the domain can be created according to the recommendations in chapter 4. The different components, timelines and synchronisations between the timelines are listed and explained Component Types and Timelines The following component types are used for modelling states of the timelines. Timelines are used to describe the evolution of systems involved in the planning process. 44

56 5.2. Design of the Domain Model Ground Station Availability Ground station availabilities are defined by a component type which can have the states visible() and not_visible(). Even though the states sound like they model visibilities, they model in fact ground station availabilities ( ). This considers already the link budget. This means that only ground station visibilities where a stable downlink can be established are taken into consideration. This component type provides facts from which Apsi only extracts information. Apsi is not allowed to change the state of the component. Therefore, it is not necessary to define transitions between the defined states. Depending on the satellite configuration, meaning Hpa in Lpm or Hpm, the ground station availability changes. This requires an individual timeline for each spacecraft configuration and ground station combination. Considering four satellites with two possible configurations each and five ground stations provided by Estrack, an overall number of 40 timelines for modelling the ground station availability results. Additionally, Mspa opportunities are represented by this component type. It identifies only opportunities and does not give any information about the possible dump rate. Mspa operation is only conducted in Lpm for now. This reduces already the number of timelines significantly. Mspa opportunities for each spacecraft pair (for example Clu3 and Clu4) needs to be modelled on two separate timelines with each satellite being the primary spacecraft on one timeline. As opportunities diverge between the ground stations, the spacecraft pairs need are modelled on timelines for each ground station. This results in 48 timelines for representing Mspa availabilities Ground Station Downlink Rate This component type has two states describing if a downlink is possible or not. It has to be considered that no downlink does not mean that the spacecraft is not visible. The states of these component type are therefore no_dl() for periods where no downlink is possible and dl(ul_bool,dumprate) representing the state which describes properties of the downlink opportunity. ul_bool describes if the ground station allows Tc uplink ( ) and dumprate provides the possible downlink rate according to the link budget (3.4.2). Transitions between those two states do not have to be specified in the domain theory as Apsi should not allocate any downlink opportunity itself, but should only extract information from it. Downlink opportunities are treated as a fact and can not be changed by the framework. Like the ground station availability, the link budget changes if the Hpa is in Hpm or Lpm. Therefore, it is necessary to create a timeline for all possible combinations. This means, the link budget for one satellite in Lpm over all five Estrack ground stations and the link budget for the same satellite in Hpm over the same ground stations needs to be modelled on different timelines. This results in overall 40 timelines considering all four spacecraft just for modelling the link budget. The link budget for Mspa opportunities requires 48 timelines, like the model representing Mspa availabilities, and models the signal strength of the secondary space- 45

57 Chapter 5. Cluster-II Scheduling Tool craft. The link budget calculation is similar to the one of regular ground station passes with the difference that the signal strength is slightly reduced due to the fact that the ground station antenna is not pointing at the secondary spacecraft which results in a small pointing loss Science Modes The Tda modes are described by a component type which is able to take five different states representing a science mode each. States representing science modes are tda2(), tda4(), tda6(), tda8() and tda6bm3() ( ). It is distinguished between a normal Tda6 and a Tda6 Burst-Mode 3 as the constraints for Dsn allow no pass during Tda6, but during a Tda6 Burst-Mode 3 which has a duration of exactly 6 min (see ). Again, no transitions between the states are allowed as the Tda modes are hard facts posted in the Pdl file. The Tda mode for each satellite is independent from the configuration of the Hpa and can not be changed. This requires one timeline describing the sequence of science modes for each individual satellite. Overall 4 timelines of this component type are required Orbital Events The orbital events component type consists of the states perigee() and apogee() representing the perigee and apogee crossing, respectively. And a state representing no event called none(). The only use of this component is the reasoning of Apsi on the orbit. An perigee crossing represents the start of a new orbit. This is of use for the modelling of the power sharing constraint (cf ) of only one pass per orbit. On the other hand, this component is mainly used for representation purposes for the Gui to imitate the ClusterWeb representation of the scheduled passes as good as possible. This component is not used for the specification of perigee transmitter off windows (this constraint is implemented in the passes and special events component, see ). Similar to before, no transitions between the states are specified. The facts are provided by the Pdl. Due to slightly different orbit trajectories of every Cluster spacecraft, the times for apogee and perigee crossing are different. This means, that overall 4 timelines, one for each satellite, describing orbital events are required Eclipse Events This component type is only used for representation purposes of the scheduling tool Gui. It has the state ecl() when the spacecraft is in an eclipse and none() if not. The constraints regarding eclipse operations are modelled in The component type provides only facts and has therefore no specified transitions between the two different states. 46

58 5.2. Design of the Domain Model Start and duration of each eclipse event is different for all spacecraft. Therefore, each spacecraft requires an individual timeline which results in 4 timelines overall for eclipse events Commands As already analysed, it is currently not possible to model the commands for the scientific instruments and the operation of the platform in Apsi. Nevertheless, this component prepares Apsi already for the further development of the scheduling tool. Special emphasis is on Wec and Edi commands, to be able to book power sharing passes in accordance with the constraints ( ). The states so far specified for the component are edi(), wec(), cis(), peace(), rapid(), fgm() describing commands regarding scientific instruments and other() representing any other command. Also command execution times are different from one spacecraft to another. Again, 4 timelines, one for each satellite, are required Ground Station Activities and Bookings Ground station configuration activities are modelled as states where a ground station can inherit only one state at a time. Besides from a state which defines a ground station as not occupied (free()), states for the Aos and Los activity as well as a state for the reconfiguration between two consecutive Cluster passes are modelled as aos(), los() and reconfigure(), respectively. The states have a duration of exactly 45 min for Aos, 15 min for Los and 10 min for the reconfiguration of the ground station ( ). To be able to identify which kind of configuration activity is necessary on the ground station, it is distinguished between bookings by a Cluster satellite and bookings of an external activity. For this, the states clu_booked() and ext_booked() are introduced to the component type. Necessary transitions can be derived by having a look at how the different states can be reached. If the ground station was booked by an external activity or was free, a Cluster booking can only be reached by going through the Aos configuration activity of the ground station first. After a Cluster booking a Los activity has to follow. A special case is the reconfiguration which comes from a Cluster booking and goes to a Cluster booking again. The Los activity can be followed by no ground station activity (free), an external booking (ext_booked()) or by another Aos (aos()) activity for the next Cluster ground station pass. Apsi generates actively new components of this type on the timeline and will move them. Therefore, the above specified transitions need to be specified in the Ddl file. Besides from external bookings, the Pdl file does not provide any other component. The described properties of this component type are schematically displayed in Figure 5.2. As all ground station activities and bookings are referring to an individual ground station, one timeline for each Estrack ground station is required. This means 5 timelines are necessary in total. 47

59 Chapter 5. Cluster-II Scheduling Tool Free [1,+INF] EXT booked LOS [15,15] AOS [45,45] CLU booked reconfig GS [10,10] Fig. 5.2.: State diagram for ground station bookings component type Passes and Special Events Ground station passes or special events affecting the ability to book passes for a spacecraft are modelled with this component type. The component can have one of the following states at a time. none(). This state has a restricted duration of 10 min at the lower bound and 2400 min ( = 40 h) for the upper bound. The lower bound implements the constraint of at least 10 min separation between two consecutive passes over two different ground stations. The upper bound corresponds to the maximum separation of two passes to avoid the overflow of the RAM Hk (see ). no_pass_possible(no_pass_reason). This state represents time frames where no passes can be conducted. The parameter no_pass_reason exists mainly for purpose to inform the user about the reason, except for one special case during eclipse operation (further explanation see ). Reasons are Wbd passes ( ), Cis operation (on Clu1, ), perigee transmitter off ( ), perigee power drop ( ), eclipse operation ( ) and pipeline and thruster pre-heating before manoeuvre ( ). fixed_pass(ground_stations, dumprate, hpa_modes, pass_type). Manoeuvre and eclipse dedicated passes are marked as fixed passes in the ClusterWeb database. Dsn passes are also imported as fixed passes. This state needs to contain the 48

60 5.2. Design of the Domain Model used ground station, the dump rate of the pass and the configuration of the spacecraft. The Hpa mode and the pass type are only necessary to be able to provide this information to the parser responsible for the generation of the PlanCWeb file which is imported to ClusterWeb afterwards. pass(ground_stations, hpa_modes, mspa_sc). An actual ground station pass scheduled by Apsi is represented by the pass state. ground_stations identifies the used ground station and hpa_modes describes the used configuration of the spacecraft from which the link budget is selected accordingly. mspa_sc defines if the pass is a Mspa primary, secondary or no Mspa pass. The allowed transitions between the different states are depicted in Figure 5.3. It can be seen that the only transition which is not allowed is the change from one pass state to the other. This is due to the fact that the automation system requires 10 min to configure between two consecutive passes of one spacecraft ( ). no pass possible pass [60,720] fixed pass none [10,2400] Fig. 5.3.: State diagram for displaying the status of the spacecraft, i.e. it represents if ground station passes are currently possible or if the satellite is conducting other activities. Parameter values are left out for keeping a good overview. A problem which might occur due to this design is the violation of the constraint taking a ground station pass every 40 h due to a no_pass_possible state between two passes. The past time since the last pass would be reseted by the insertion of such an event. Nevertheless, it is still possible to avoid this violation by implementing a post-processing functionality which checks for this constraint explicitly. Passes and special events are always referring to one individual spacecraft. This results in 4 timelines for this component type to avoid the overlapping of multiple actions on a single spacecraft SSR Fill Level The component type for modelling the Ssr fill level is a reservoir resource. The component has a lower bound of 0 which is equivalent to a completely emptied onboard memory. The upper bound of the resource is bit, equal to 7.5 Gbit. This component type requires 4 timelines, one for each spacecraft. 49

61 Chapter 5. Cluster-II Scheduling Tool Synchronisations Synchronisations are used to combine information from multiple timelines. This is necessary to implement some constraints. The synchronisation types used in the domain model of Cluster scheduling are listed below in Figure 5.4. A [l s,u s] [l e,u e] B (a) A CONTAINS[l s,u s ][l e,u e ] B. A [l s,u s] [l e,u e] B (b) A DURING[l s,u s ][l e,u e ] B. B (c) A STARTS DURING[l s,u s ][l e,u e ] B. A [l s,u s] [l e,u e] A [l s,u s] [l e,u e] B (d) A ENDS DURING[l s,u s ][l e,u e ] B. A [0,0] B (e) A MEETS B. [lb,ub] A B (f) A AFTER[lb,ub] B. A [0,0] [0,0] B (g) A EQUALS B. Fig. 5.4.: A representation of the used types of synchronisation for the Cluster domain. For most synchronisations, lower and upper bounds have to be considered. Of course, Apsi provides many more synchronisations which are not presented to keep the focus on the Cluster domain. The following sections describe how the displayed synchronisations are used for modelling the constraints of Cluster planning and scheduling. 50

62 5.2. Design of the Domain Model Science Modes The science mode timelines of each spacecraft are synchronised to Ssr fill level timeline of the same spacecraft. The Tda mode EQUALS a production activity of the Ssr. The amount of produced data depends on the science mode of the spacecraft Power Down Eclipses Before eclipse entry, the spacecraft needs to be switched off. To avoid the loss of Ssr data, the memory must be dumped completely before eclipse entry. A no pass possible frame is defined around each power down eclipse. A synchronisation between this frame and a function which tells Apsi to empty the Ssr completely before entering the no pass possible frame takes care of this constraint. The used synchronisation here is AFTER. By imposing that between 30 min and 45 min after the Ssr has been emptied a no pass possible frame should start, Apsi moves the command to empty the memory at the given point in time before the frame starts. The flexibility needs to be introduced to give Apsi some more possibilities. Otherwise the framework would try to bring the Ssr fill level down to zero exactly to the microsecond. This can result in problems for the allocation of previous passes as the duration might have to change for very small fractions of time. This may not be the most intuitive design, but the simplest. After the eclipse, the spacecraft is rebooted and the value of the Ssr fill level needs to be reseted to zero to model the fact that no data has actually been produced during the eclipse phase. Otherwise Apsi would take the production rate of the Tda mode during the eclipse and generate a fill level which needs to be downloaded Passes For taking passes, Apsi has to consider multiple synchronisations. First, it has to be differentiated between passes with a single bit rate and passes where the bit rate changes. Instead of modelling the dumped data by applying an ACTIVITY to the Ssr timeline, a new resource function called SET_SLOPE is used. This function neglects all applied activities on the timeline and considers only the effect of SET_SLOPE. Single Bit Rate Pass: For a ground station pass with a single bit rate, one synchronisation to the Ssr timeline has to be done. The Ssr dump time has to respect the configuration time of the spacecraft after Aos and before Los. Therefore, the pass CONTAINS a SET_SLOPE activity with the defined margins of 9 min and 1 min. Depending on the link budget, the slope rate is either bps or bps in Lbr or Hbr, respectively. Furthermore, this Ssr synchronisation has to be DURING a downlink opportunity of a singular bit rate. To consider the constraint of no Tda change within the first 15 min and last 6 min, synchronisations with STARTS_DURING and ENDS_DURING have to be done. To be able to identify the correct configuration jobs before and after the ground station pass, a further synchronisation to the ground station booking timeline needs to be done. This synchronisation adds a cluster booking which EQUALS the pass start and end time on the timeline of the corresponding ground station. 51

63 Chapter 5. Cluster-II Scheduling Tool Mixed Bit Rate Pass: Ground station passes with a mixed downlink rate are very similar to single bit rate passes. The difference is that two SET_SLOPE synchronisations to the Ssr timeline are necessary. Furthermore, the two downlink rates have to be connected to each other which is implemented by using the MEETS synchronisation. The configuration margins are respected by using two different CONTAINS synchronisations whereas one is responsible for the first bit rate and keeping the margin of 9 min after Aos before the Ssr dump can be started. The other one is responsible for ending the data dump 1 min before Los. Synchronisations to the ground station bookings and Tda mode timeline are the same as for a single bit rate pass. Fixed Pass: The implementation of fixed passes require less synchronisations than for passes which are scheduled by Apsi. In principle, it should be assumed that fixed passes satisfy all constraints of ground station bookings. As already explained, fixed passes with multiple downlink rates are split into separate fixed passes with only one downlink rate. This means, for each fixed pass only one synchronisation to the Ssr timeline needs to be done. The SET_SLOPE activity is contained by the pass to respect the configuration margins. 1 For the ground station configuration activities a Cluster booking synchronisation which also EQUALS the start and duration of the pass needs to be done with the ground station bookings timeline. Besides from that, no further synchronisations are required for fixed passes Implementation The implementation of the interfaces, Ddl and Pdl files are described in this section below. The Pdl is of course changing whenever a new scenario is defined. Therefore, it should be seen as an example Interfaces The here presented interfaces were implemented in order to provided easy and quick access to the data. They were designed in a way that changes of constraint in future mission operations are anticipated and an adaptation of the source code is not necessary unless severe modifications are required ClusterWeb to Scheduling Tool The tool which is responsible for creating the Pdl file is a web page, part of the planning section in ClusterWeb (cf. Figure 5.5). 1 The problem here is that a fixed pass with a change in the bit rate would result in a 10 min gap of data dump at the time the bit rate change happens. This gap does not exist in reality and is an inaccuracy of the Ssr model, but in that case it is better to overestimate the Ssr fill level than underestimating it. 52

64 5.3. Implementation Fig. 5.5.: Apsi input tool in the planning section of ClusterWebwith additional options hidden. The Apsi input tool is mainly developed in php and uses MySQL queries to access the database. The animation processes and validity checks of the form are implemented by using jquery and JavaScript functions. According to the selected options (where the main topics can be folded or unfolded in order to increase the overview or to select more options, see Figure C.1 and Figure C.2 in Appendix C), the user interface initiates the pre-processing of the required data. The tool sends multiple queries to the ClusterWeb database and filters the information appropriately and writes it in a Pdl file. The produced Pdl file is then downloaded from the ClusterWeb server, available for the further procedure of creating a ground station schedule GUI Scheduling Tool A screenshot of the scheduling tool itself is displayed in Figure 5.6. The tool s main display is based on the representation of ground station pass scheduling in ClusterWeb (see Fig. 2.1 in chapter 2 for comparison). This includes the different Tda modes for the spacecraft, the Ssr fill level, ground station visibil- 53

65 Chapter 5. Cluster-II Scheduling Tool Fig. 5.6.: Screenshot of the scheduling tool, displaying a solved ground station plan. ities and ground station bookings. The represented solved plan covers a period of 3.5 days during which four ground station passes have been allocated whereas the first scheduled ground station pass on Clu2 has been scheduled before and is a fixed pass which can not be deleted or moved by the tool. All other passes have been automatically scheduled by the tool. Pass properties are represented by the different colour pattern of the boxes. A Lbr pass has a yellow pattern and a Hbr pass has a green pattern, for example. Red patterns in the timeline of each spacecraft indicate periods where no pass can be scheduled (Cis operation on Clu1 on late 6 th of March, as an example). Hovering over the different elements of the schedule will provide the user with more detailed information about the event. This can be seen by the orange box in the top right side of the plan which gives exact pass times and downlink rates. The right side pane contains elements to control the tool. The controls in the top initiate the solving process and the creation of the output file. The selectable options in the middle allow to manipulate the plan representation in the main display. With the multiple available options, the user is able to create a view which is suitable for him to identify good plan. The overview of the schedule can be for example increased by disabling the ground station visibilities which reduces the number of elements displayed in the schedule significantly. The control elements at the bottom of the right side pane allow the user to navigate through the plan and change the zoom level. These actions can also be done by clicking in the main display with the mouse and moving it to the right or left side. The zoom level can be changed by using the mouse wheel. The bottom pane displays the currently selected scenario and the found solutions. It is also possible to display multiple solutions for a single scenario by selecting 54

66 5.3. Implementation them. The expand option allows to highlight and enlarge one solution to inspect and compare it with the others. Multiple solutions have a different pass colouring. A numeric representation of plan properties enables the operator to judge on the quality of a plan based on different criteria. The columns can be arranged in an arbitrary order and hidden if the user wishes so. The preferred user settings are saved automatically or can be exported if different views are desired. The tool s pane arrangement is dynamically and can be changed to the user s needs. The bottom pane can be increased, as well as the side pane. If the user wants to focus on the main display, the side and bottom pane can be reduced to a minimum size which will hide them Scheduling Tool to ClusterWeb The PlanCWeb file produced by Apsi can be imported to ClusterWeb via the import function displayed in Figure 5.7. Fig. 5.7.: PlanCWeb import tool (highlighted red box) in the import data section of ClusterWeb. As shown in the tool s function description, it deletes all ground station passes in the validity range of the file, except for passes dedicated to special activities 55

67 Chapter 5. Cluster-II Scheduling Tool like eclipses or manoeuvres. Besides from fixed passes, all passes defined in the PlanCWeb file are imported to the database Domain Definition Language Modelling The domain theory of Cluster is implemented by making use of data types, component types and resources provided by Apsi. This section presents the implementation of the constraints according to the design models Data Types The parameter values of state variables are defined as data types. It must be distinguished between enumerations which have fixed predefined values on which can be reasoned by the Apsi solvers and objects which behave basically like a string. Apsi solvers are not able to reason on object data. In total, the Cluster domain makes use of seven data types identified and explained during the design description above. They are defined and implemented as following: DATA TYPE ENUMERATION g r o u n d s t a t i o n s = {MSP, NNO, PER, KRU, VL2, D14, D15, D24, D27, D34, D45, D54, D55, D65, DSN} ; DATA TYPE ENUMERATION u l b o o l = { ul, n o ul } ; DATA TYPE ENUMERATION hpa modes = {LPM, HPM} ; DATA TYPE ENUMERATION mspa sc = { primary, secondary, none } ; DATA TYPE ENUMERATION dumprate = { lbr, hbr } ; DATA TYPE ENUMERATION n o p a s s r e a s o n = {wbd, c i s, p e r t x o f f, s i x t x o f f, e c l i p s e s s r o f f, e c l i p s e s s r o n, r c s p r e h e a t i n g, other } ; DATA TYPE OBJECT s t r i n g ; Component Types and Timelines The different component types are implemented on timelines as following: Ground Station Availability (see ): Ground station availabilities are modelled by this component type. It is not required to specify available transitions between the states. COMP TYPE GROUND STATE VARIABLE SV GSV VALUES { n o t v i s i b l e ( ) ; <OPPORTUNITY> v i s i b l e ( ) ; } TRANSITIONS {} 56 <OPPORTUNITY> gives the solver an indication that a pass can be allocated when the availability timeline has a visible state. For times during which an opportunity is taken, no other activity can overlap. The implementation of timelines presented below models the availability for all Estrack ground stations with the spacecraft s Hpa operated in Hpm. An

68 5.3. Implementation additional timeline, very similar to this one, representing the availabilities in Lpm is required. The difference between these timelines for other spacecraft is only the satellite number. COMPONENT SV GSV clu1 hpm vis { FIX EST <FACT, PROVIDES OPPORTUNITY passes c l u 1 t i m e l i n e > msp timeline ; FIX EST <FACT,PROVIDES OPPORTUNITY passes c l u 1 t i m e l i n e > n n o t i m e l i n e ; FIX EST <FACT, PROVIDES... } To complete the component from above, the remaining Estrack ground stations timelines need to be added the same way the timelines Msp and Nno have been defined. FIX_EST imposes to the solver to take the earliest possible start point on the flexible timeline. FACT tells the solver that this timeline only contains facts on which it can be reasoned, but the solver is not allowed to change the timeline. PROVIDES_OPPORTUNITY-passes-clu1_timeline can be considered as some kind of synchronisation which relates the opportunities to the timeline where the activities are placed on (passes-clu1_timeline, implemented below). Furthermore, this component type implements Mspa opportunities. It represents opportunities where Mspa operation is possible for a ground station. COMPONENT SV GSV c l u 1 c l u 2 o p p { FIX EST msp timeline ; FIX EST n n o t i m e l i n e ; FIX EST p e r t i m e l i n e ;... } The naming convention for this timeline is that the first named spacecraft is the primary and the second named the secondary. In this case Clu2 would take the shadow track of Clu1. The... need to be replaced with the remain Estrack ground stations. Furthermore, components modelling each spacecraft pair need to be added to complete the model where each spacecraft is primary for all possible combinations. Ground Station Downlink Rate (see ): The component type describes if a downlink is possible or not and if Tc uplink is available. It is not required to specify available transitions between the states. COMP TYPE STATE VARIABLE SV GSD VALUES { n o d l ( ) ; dl ( u l b o o l, dumprate ) ; } TRANSITIONS {} The implementation of this component models the link budget on timelines for each Estrack ground station. The component presented below represents the link budget for Clu1 with the Hpa operated in Hpm. COMPONENT SV GSD clu1 hpm dl { FIX EST msp timeline ; FIX EST n n o t i m e l i n e ; FIX EST p e r t i m e l i n e ;... } To complete the model, components for each spacecraft configuration (Hpm and Lpm) and each spacecraft need to be added. 57

69 Chapter 5. Cluster-II Scheduling Tool Additionally, the possible downlink rates for Mspa secondary passes are modelled on timelines using the same component type. This means, that in the presented example from below the link budget for a shadow pass of Clu2 is modelled. COMPONENT SV GSD c l u 1 c l u 2 d l { FIX EST msp timeline ; FIX EST n n o t i m e l i n e ; FIX EST p e r t i m e l i n e ;... } The naming convention is identical to the one of Mspa availabilities introduced above. Science Modes (see ): Model of the five required Tda modes for scheduling. It is not required to specify available transitions between the states. COMP TYPE GROUND STATE VARIABLE SV TDA VALUES { tda2 ( ) ; tda4 ( ) ; tda6 ( ) ; tda6bm3 ( ) ; tda8 ( ) ; } TRANSITIONS {} For the implementation of the Tda modes only one component with four timelines, one for each spacecraft, is necessary. COMPONENT SV TDA tda modes { FIX EST c l u 1 t i m e l i n e ; FIX EST c l u 2 t i m e l i n e ; FIX EST c l u 3 t i m e l i n e ; FIX EST c l u 4 t i m e l i n e ; } Orbital Events (see ): Orbital events are used for representation and orbit determination purposes. It has to be considered that apogee() and perigee() are instants of time. It is not required to specify available transitions between the states. COMP TYPE GROUND STATE VARIABLE SV OEVENTS VALUES { none ( ) ; p e r i g e e ( ) ; apogee ( ) ; } TRANSITIONS {} Orbital events are placed on an individual timeline for each spacecraft belonging to one component. COMPONENT SV OEVENTS oevents { FIX EST c l u 1 t i m e l i n e ; FIX EST c l u 2 t i m e l i n e ; FIX EST c l u 3 t i m e l i n e ; FIX EST c l u 4 t i m e l i n e ; } 58

70 5.3. Implementation Eclipse Events (see ): Eclipse events are only used for representation purposes of the scheduling tool. It is not required to specify available transitions between the states. COMP TYPE STATE VARIABLE SV ECL VALUES { none ( ) ; e c l ( ) ; } TRANSITIONS {} Eclipses are placed on an individual timeline for each spacecraft belonging to one component. COMPONENT SV ECL e c l i p s e s { FIX EST c l u 1 t i m e l i n e ; FIX EST c l u 2 t i m e l i n e ; FIX EST c l u 3 t i m e l i n e ; FIX EST c l u 4 t i m e l i n e ; } Commands (see ): This component type models commands for each used instrument. So far, this component is not considered during the automated planning process. It is not required to specify available transitions between the states. COMP TYPE GROUND STATE VARIABLE SV CMD VALUES { none ( ) ; e d i ( ) ; wec ( ) ; c i s ( ) ; peace ( ) ; rapid ( ) ; fgm ( ) ; other ( ) ; } TRANSITIONS {} Similar to the components above, the commands are placed on an individual timeline for each spacecraft belonging to one component. COMPONENT SV CMD commands { FIX EST c l u 1 t i m e l i n e ; FIX EST c l u 2 t i m e l i n e ; FIX EST c l u 3 t i m e l i n e ; FIX EST c l u 4 t i m e l i n e ; } Ground Station Activities and Bookings (see ): Ground station activities and bookings are implemented by the component type presented below. The specification of transitions is very important for this component type. It ensures that the correct configuration activities are selected before and after a ground station pass. Time restrictions on certain states are specified according to the design. COMP TYPE GROUND STATE VARIABLE SV GSB VALUES 59

71 Chapter 5. Cluster-II Scheduling Tool { DEFAULT f r e e ( ) [1,+INF ] ; NOT ON COMPLETION ext booked ( ) ; NOT ON COMPLETION clu booked ( ) ; aos ( ) [ 0 0 : 4 5, 0 0 : 4 5 ] ; l o s ( ) [ 0 0 : 1 5, 0 0 : 1 5 ] ; r e c o n f i g u r e ( ) [ 0 0 : 1 0, 0 0 : 1 0 ] ; } TRANSITIONS { f r e e ( ) TO { aos ( ) ; } f r e e ( ) TO { ext booked ( ) ; } ext booked ( ) TO { f r e e ( ) ; } ext booked ( ) TO { aos ( ) ; } aos ( ) TO { clu booked ( ) ; } clu booked ( ) TO { r e c o n f i g u r e ( ) ; } r e c o n f i g u r e ( ) TO { clu booked ( ) ; } clu booked ( ) TO { l o s ( ) ; } l o s ( ) TO { ext booked ( ) ; } l o s ( ) TO { f r e e ( ) ; } l o s ( ) TO { aos ( ) ; } } The DEFAULT value is used to complete the timeline. This component requires one timeline per ground station where the actual activities are booked on. The initially known bookings of external activities are also put on these timelines. COMPONENT SV GSB g s b o o k i n g s { FLEXIBLE <COMPLETE> msp t i m e l i n e ; FLEXIBLE <COMPLETE> n n o t i m e l i n e ;... } Passes and Special Events (see ): All passes and special events which affect the planning of passes are implemented by this component type. 60 COMP TYPE STATE VARIABLE SV PASSES VALUES { none ( ) [ 0 0 : 1 0, 0 0 : ] ; n o p a s s p o s s i b l e ( n o p a s s r e a s o n ) ; f i x e d p a s s ( g r o u n d s t a t i o n s, dumprate, s t r i n g, s t r i n g ) ; <CONSUME ,NEED OPPORTUNITY> p a s s ( ground s t a t i o n s, hpa modes, mspa sc ) [ 0 1 : 0 0, 1 2 : 0 0 ] ; } TRANSITIONS { none ( ) TO { pass (? gs,?hpa mode,?mspa ) ; } none ( ) TO { n o p a s s p o s s i b l e (? reason ) ; } none ( ) TO { f i x e d p a s s (? gs,? rate,?hpa,? type ) ; } pass (? gs,?hpa mode,?mspa ) TO { none ( ) ; } pass (? gs,?hpa mode,?mspa ) TO { n o p a s s p o s s i b l e (? reason ) ; } n o p a s s p o s s i b l e (? reason ) TO { pass (? gs,?hpa mode,?mspa ) ; }

72 5.3. Implementation } n o p a s s p o s s i b l e (? reason ) TO { none ( ) ; } n o p a s s p o s s i b l e (? reason ) TO { f i x e d p a s s (? gs,? rate,?hpa,? type ) ; } f i x e d p a s s (? gs,? rate,?hpa,? type ) TO { none ( ) ; } f i x e d p a s s (? gs,? rate,?hpa,? type ) TO { n o p a s s p o s s i b l e (? reason ) ; } The CONSUME_-93_-199 tag is an additional information for the solver to reduce the solving time. It tells the solver the minimum and maximum consumption and bounds the reasoning. NEED_OPPORTUNITY is the counter part of PROVIDES_OPPORTUNITY specified in the component type for ground station availabilities. This means that the timeline can take the state pass only if an opportunity is available and it is not taken by another pass. The component type is used for implementing four timelines, one for each spacecraft. COMPONENT SV PASSES p a s s e s { FLEXIBLE <CONSUMES c l u 1 s s r t i m e l i n e > c l u 1 t i m e l i n e ; FLEXIBLE <CONSUMES c l u 2 s s r t i m e l i n e > c l u 2 t i m e l i n e ;... } CONSUMES-clu1_ssr_timeline corresponds to the tag presented above to provide the solver some additional information which enhances the solving process. SSR Fill Level (see ): The definition of the Ssr component type is very simple. COMP TYPE RESERVOIR RESOURCE SSR ; The implementation of the component defines the lower and upper boundary of the resource. It is strictly forbidden for the solver to go below or above the defined thresholds. The maximum capacity the Ssr is 7.5 Gbit. The thresholds are define in bits. COMPONENT SSR s s r f i l l l e v e l { FLEXIBLE c l u 1 s s r t i m e l i n e ( 0. 0, ) ; FLEXIBLE c l u 2 s s r t i m e l i n e ( 0. 0, ) ;... } The definition of the timeline for Clu3 and Clu4 is the same as for Clu1 and Clu Synchronisations The Ddl is a very low level language which means that each synchronisation needs to be defined specifically for each timeline. So even if timelines share the same synchronisation properties, it is not possible to define these properties for groups of timelines. This results in a very huge Ddl file. The following synchronisation are only examples for one type of synchronisation. In most cases the presented synchronisations need to be rewritten for all kind combinations of ground stations, spacecraft, spacecraft configuration, etc.. 61

73 Chapter 5. Cluster-II Scheduling Tool Science Modes The Tda modes have synchronisations to the Ssr timeline of each spacecraft and assign an activity to the timeline with the according production rate given in kbps. SYNCHRONIZE tda modes. c l u 1 t i m e l i n e { VALUE tda2 ( ) { cd1 <!> s s r f i l l l e v e l. c l u 1 s s r t i m e l i n e. ACTIVITY( ) ; EQUALS cd1 ; }... } SYNCHRONIZE tda modes. c l u 2 t i m e l i n e... EQUALS cd1; can be read as: Tda2 equals condition 1 which represents the activity. The presented implementation above needs to be extended with all Tda modes and the synchronisation of spacecraft Clu2, Clu3 and Clu4. Passes The different pass types, implemented below, are all contained in the following SYNCHRONIZE statements. SYNCHRONIZE p a s s e s. c l u 1 t i m e l i n e { VALUE pass (NNO,LPM,? mspa ) {... }... } SYNCHRONIZE p a s s e s. c l u 2 t i m e l i n e... Each spacecraft needs an own SYNCHRONIZE for modelling the passes. Besides from the timelines referring to one of the four spacecraft timelines, the content of the synchronisations are the same. Single Bit Rate Passes This synchronisation is an example of a Lbr opportunity in Lpm configuration of Clu1. The ground station pass is booked for Nno. 62 VALUE pass (NNO,LPM,? mspa ) { LBR s s r f i l l l e v e l. c l u 1 s s r t i m e l i n e. SET SLOPE( 93207); LBR V c l u 1 l p m d l. n n o t i m e l i n e. dl (? u l b o o l, l b r ) ; CONTAINS[ 0 0 : 0 9, 0 0 : 0 9 ] [ 0 0 : 0 1, 0 0 : 0 1 ] LBR; LBR DURING LBR V ; BOOK <!> g s b o o k i n g s. n n o t i m e l i n e. clu booked ( ) ; EQUALS BOOK; c d s t a r t tda modes. c l u 1 t i m e l i n e. ;

74 5.3. Implementation } cd end tda modes. c l u 1 t i m e l i n e. ; STARTS DURING[00:00,+INF ] [ 0 0 : 1 5, + INF ] c d s t a r t ; ENDS DURING[00:06,+INF ] [ 0 0 : 0 0, + INF ] cd end ; Passes which have only one bit rate during their full duration require only one synchronisation to the Ssr timeline. This SET_SLOPE activity is contained by the pass. The last two synchronisations ensure that Aos is scheduled at least 15 min before a Tda change and Los is scheduled at least 6 min after a science change. Mixed Bit Rate Passes Ground station passes with a mixed bit rate need to be implemented separately, whereas the sequence of bit rates must be exactly defined. Besides from that, the implementation is very similar to single bit rate passes. The presented code below is an example for a pass with a change from Lbr to Hbr. VALUE pass (NNO,LPM,? mspa ) { LBR s s r f i l l l e v e l. c l u 1 s s r t i m e l i n e. SET SLOPE( 93207); HBR s s r f i l l l e v e l. c l u 1 s s r t i m e l i n e. SET SLOPE( ); } LBR V c l u 1 l p m d l. n n o t i m e l i n e. dl (? u l b o o l 1, l b r ) ; HBR V c l u 1 l p m d l. n n o t i m e l i n e. dl (? u l b o o l 2, hbr ) ; LBR DURING LBR V ; HBR DURING HBR V; BOOK <!> g s b o o k i n g s. n n o t i m e l i n e. clu booked ( ) ; EQUALS BOOK; CONTAINS[ 0 0 : 0 9, 0 0 : 0 9 ] [ 0 0 : 0 0, + INF ] LBR; CONTAINS[00:00,+INF ] [ 0 0 : 0 1, 0 0 : 0 1 ] HBR; LBR MEETS HBR; c d s t a r t tda modes. c l u 1 t i m e l i n e. ; cd end tda modes. c l u 1 t i m e l i n e. ; STARTS DURING[00:00,+INF ] [ 0 0 : 1 5, + INF ] c d s t a r t ; ENDS DURING[00:06,+INF ] [ 0 0 : 0 0, + INF ] cd end ; Passes with more than one bit rate change are very unlike to happen and are not considered, yet. The only change in the code which has to be done for a high to low bit rate implementation is adapting the CONTAINS and MEETS synchronisations in the fifth code block. Fixed Passes The implementation of fixed passes is much shorter than for passes which have to scheduled by Apsi as no constraint check is necessary. VALUE f i x e d p a s s (NNO, hbr,?hpa,? type ) { HBR s s r f i l l l e v e l. c l u 1 s s r t i m e l i n e. SET SLOPE( ); 63

75 Chapter 5. Cluster-II Scheduling Tool } CONTAINS[ 0 0 : 0 9, 0 0 : 0 9 ] [ 0 0 : 0 1, 0 0 : 0 1 ] HBR; BOOK <!> g s b o o k i n g s. n n o t i m e l i n e. clu booked ( ) ; EQUALS BOOK; As mentioned in the design, the implementation has a slight inaccuracy for fixed passes with changing bit rate as a 10 min dump gap is inevitable with the current implementation. Power Down Eclipse This synchronisation tells Apsi to bring the Ssr fill level to zero before the spacecraft is switched off. VALUE n o p a s s p o s s i b l e (? reason = e c l i p s e s s r o f f ) { REQ s s r f i l l l e v e l. c l u 1 s s r t i m e l i n e.level( 0. 0, 0. 0 ) ; AFTER[ 0 0 : 3 0, 0 0 : 4 5 ] REQ; } Problem Definition Language Modelling The here presented implementation of a Pdl file should give an impression of how the information from the ClusterWeb database is processed and converted to a format which can be loaded to Apsi. Ground Station Availability and Downlink Rate Ground station availability and the corresponding downlink rates are always generated together. After an availability has been found its link budget is analysed and split in different statements in the Pdl if necessary. This is an example for a Hbr availability with the Hpa in Lpm for Clu1 over Vl2: g s i n i t 0 <FACT> STATIC c l u 1 l p m d l. v l 2 t i m e l i n e. dl ( ul, hbr ) AT [ T23 : 3 2 : Z, T02 : 4 6 : Z ] ; g s i n i t 1 <FACT> STATIC c l u 1 l p m v i s. v l 2 t i m e l i n e. v i s i b l e ( ) AT [ T23 : 3 2 : Z, T02 : 4 6 : Z ] ; The same availability with two different bit rates would look like the following: g s i n i t 0 <FACT> STATIC c l u 1 l p m d l. v l 2 t i m e l i n e. dl ( ul, hbr ) AT [ T23 : 3 2 : Z, T00 : 1 4 : Z ] ; g s i n i t 1 <FACT> STATIC c l u 1 l p m d l. v l 2 t i m e l i n e. dl ( ul, l b r ) AT [ T00 : 1 4 : Z, T02 : 4 6 : Z ] ; g s i n i t 2 <FACT> STATIC c l u 1 l p m v i s. v l 2 t i m e l i n e. v i s i b l e ( ) AT [ T23 : 3 2 : Z, T02 : 4 6 : Z ] ; 64 The <FACT> tag tells the solver that no conflict removal for these components is necessary. Mspa opportunities are modelled in the same way with the difference that the timelines are named differently.

76 5.3. Implementation Science Modes According to sequences saved in the ClusterWeb database, the science modes are extracted and posted on the spacecraft timelines. t d a i n i t 0 <GOAL> STATIC tda modes. c l u 1 t i m e l i n e. tda4 ( ) AT [ T00 : 0 0 : Z, T00 : 0 9 : Z ] ; The <GOAL> tag tells the solver that this statement has an influence on the goal which should be justified by the planner. In the Cluster case this is to keep the Ssr fill level as low as possible. All other Tda modes are stated in the same way. Orbital and Eclipse Events Orbit events are time instants and are therefore differently stated than time intervals. o e i n i t 0 <FACT> STATIC oevents. c l u 1 t i m e l i n e. p e r i g e e ( ) AT [ T18 : 1 3 : Z ] ; Eclipses are only used for displaying purposes in the scheduling tool. The solver does not use this timeline. e c l i n i t 0 <FACT> STATIC e c l i p s e s. c l u 1 t i m e l i n e. e c l ( ) AT [ T22 : 4 8 : Z, T23 : 1 0 : Z ] ; Commands As commands are currently not available for the planning, this is not respected during the creation of the Pdl file. Ground Station Bookings During the creation of the Pdl file, it is only necessary to post all external bookings from the ClusterWeb database. Cluster bookings of fixed passes are automatically synchronised by the solver. The reason for the external booking is irrelevant for the solving process and is not extracted from the database. g s b i n i t 0 <FACT> STATIC g s b o o k i n g s. p e r t i m e l i n e. ext booked ( ) AT [ T14 : 3 8 : Z, T12 : 5 3 : Z ] ; Passes and Special Events Fixed passes and special events affecting the ability to book passes are state as shown below. e c l i n i t 1 <GOAL> STATIC p a s s e s. c l u 1 t i m e l i n e. f i x e d p a s s ( vl2, hbr,lpm,rxpn) AT [ T12 : 4 2 : Z, T16 : 2 4 : Z ] ; e c l i n i t 2 <GOAL> STATIC p a s s e s. c l u 1 t i m e l i n e. f i x e d p a s s (msp, hbr,lpm,rxrn) AT [ T23 : 3 8 : Z, T01 : 3 8 : Z ] ; e c l i n i t 3 <FACT> STATIC p a s s e s. c l u 1 t i m e l i n e. n o p a s s p o s s i b l e ( e c l i p s e s s r o f f ) AT [ T16 : 2 4 : Z, T23 : 3 8 : Z ] ; The here presented statements belong to the eclipse event described above. The first fixed pass is a switch off pass, the secondary a recovery pass, identifiable by the pass type (RXPN for switch off and RXRN for recovery). Between 65

77 Chapter 5. Cluster-II Scheduling Tool these two passes, no other pass shall be booked. Therefore, the insertion of a no_pass_possible(eclipse_ssr_off) period. Fixed passes have the tag <GOAL> as they influence the evolution of the Ssr fill level. No pass possible events and fixed passes are implemented the same way for manoeuvre dedicated passes and no pass reasons different than eclipses. Initial SSR Fill Level The initial Ssr fill level of the spacecraft needs to be stated in the Pdl file. This is done by using the statement below for each spacecraft and defining the fill level in bits. INIT VALUE s s r f i l l l e v e l. c l u 1 s s r t i m e l i n e = ; 66

78 Chapter 6. Results The development of the scheduling tool experienced major delays during the implementation and design period. Most delays were caused by the necessity for new components, like the reservoir resource, and planners, like Plasma, for the framework. Especially the task to control the resource level as a driving factor for the allocation of pass activities requires new planning and scheduling strategies from Apsi. To achieve this, Hso-Osa undertook huge efforts and invested a great amount of time. Nevertheless, it was not possible to develop the framework so far that the scheduling tool can be used operationally. The model of the Cluster domain is completed and has been validated and tested as far as possible with the current state of the planner. The domain comprises currently more than 2000 lines of code, whereas the required component types and timelines are described within about 200 lines. The rest of the Ddl contains the definition of synchronisations between the different timelines and states. This is due to the fact that the Ddl is a very low level language, which means that each synchronisation has to be defined individually. Considering all possible combinations of bit rates during a pass and all available ground station and spacecraft combination, this number gets very fast very big. A reduction of the Ddl s size is not possible unless further development on the framework has been done. The pre-processing function and Pdl generator, integrated into ClusterWeb, has also been tested and validated with accordance to the present domain model. Problems spanning over a planning period of one week have a size of slightly more than 1000 lines. Mostly information about ground station availabilities and their corresponding downlink rates are responsible for this. Each ground station availability has to be modelled for each spacecraft configuration. So, with approximately 50 ground station availabilities per spacecraft in one week and at least two different configurations (Hpa in Lpm and ranging enabled or disabled), not forgetting the possibility of multiple bit rates during one availability, it is not possible to reduce the number without omitting information. One way of reducing the Pdl size is to disregard the fact that enabled ranging worsens the signal-to-noise ratio of the communication link and conduct ranging on a best effort basis whenever the link budget allows it. This practice is actually performed at the moment and does not have a big impact on mission operation, but considering the closure of Per in 2016, no Tc-uplink capabilities at Nno and the more frequent use of Mspa, ranging might not be possible during two consecutive passes and this constraint will become more important in the next years. 67

79 Chapter 6. Results Even though Mspa opportunities depend heavily on the orbit constellation and occurrences are very limited at the moment, an orbit change of Clu3 and Clu4 in late 2015 to an inter-satellite distance of a couple of kilometres will provide an increased number of possibilities to conduct Mspa operation. The more frequent use of Mspa in the future will also increase the size of the Pdl as Mspa opportunities are not considered yet. Despite that, it can be said that the pre-processing function does reduce the size of the search space for the solver already greatly by neglecting availabilities where ground station passes can not be taken due to bad signal-to-noise ratio. Figure 6.1 displays an automatically generated ground station pass plan for the calendar week starting with the 6 th of July The Pdl file has manually been changed to not contain any ground station bookings from other missions or maintenance during this planning period. The reason for this is that the solver algorithm is not yet optimised to handle problems of this size and crashes. In fact, it is able to solve smaller problems with existing bookings which can be observed in Figure 5.6, even though not all constraints are fully considered by the planner yet. Fig. 6.1.: Automatically generated ground station pass schedule for one week without ground station bookings starting on the 6 th of July The created plan reveals the basic behaviour of the used solving algorithm. It can be observed that the solver reacts on high Ssr fill level at the point in time when the on-board memory would overflow and starts scheduling passes at the next earliest possibility before the overflow occurs. Additionally, the solver strictly avoids underflows of the Ssr fill level. This means, the on-board memory will never go below zero for a longer period of time. At the time of the submission of this thesis, Hso-Osa worked on the optimisation of the solver to not only avoid an overflow of 68

80 the memory but to implement the solver in a way that the fill level is kept as low as possible. Figure 6.2 gives a further insight in the solving process of the Cluster scheduling tool. The graphic displays the decision network which was created during the process of automated pass generation for the week specified above. Furthermore, this tree structure shows that the solver is using a depth-first search for finding a solution. This has the reason that a breadth-first search would result in huge search space for all ground station availabilities of a spacecraft. The required time to find a solution would be exceptionally bigger than for a depth-first search. Activities which are cut off on top of this graph are only initialisation processes of putting the Tda modes and other predefined components on the timelines before the actual solving process starts. Fig. 6.2.: Tree structure representation of the solving process for the week of the 6 th of July

81 Chapter 6. Results A zoomed perspective of the second last pass decision of the above presented graph is displayed in Figure 6.3. Fig. 6.3.: Zoomed perspective of the tree structure representation of the solving process for the week of the 6 th of July Starting from the top of this figure, it can be observed that the solver found an overflow of the Ssr fill level and decided to generate a new resource activity to solve the flaw. The big box represents a found pass opportunity. The reasoner can either allocate a Hbr or a Lbr pass whereas it always tries to allocate the high bit rate first (left side). After the decision to use a Hbr activity, the solver synchronises the pass to the bookings timeline and checks for collision with other bookings. The third and fourth step check if the distance of Aos and Los is big enough to the next Tda change. After that, the solver tries to synchronise to the bit rate timeline. This step fails in the presented example due to the fact that no Hbr exists for the chosen time of the pass. The Lbr pass on the other hand is possible and fulfils all requirements. Finally, the reasoner checks if the so far allocated passes are sufficient to cover the planning period without causing an overflow of the Ssr. This is not the case and the resource activity generator initiates the creation of another pass. The solving process terminates when no overflow is detected until the end of the defined planning period. The implemented solver is deterministic. This means that the produced plans are reproducible if the used Ddl and Pdl files are the same. The intention behind this is to prevent the user from executing multiple solving processes for the same problem and hoping for a better solution. Furthermore, it should be comprehensible why the solver took a decision and not randomised. The decision to use the Ddl and Pdl formats for defining the domain and problem, respectively, proved to be the right choice during the process of debugging. With this approach, it is easily possible to study the behaviour of the solver for different domains. Furthermore, scenarios can easily be changed, manipulated and extended to the debugging needs. 70

82 Chapter 7. Outlook and Further Work As already pointed out in the results, the tool is not yet ready to be deployed in an operational environment. For this, further steps are required. First, of course, the scheduling framework Apsi needs to be extended and optimised to be able to solve problems of the size of the Cluster domain. A way to increase the solving speed significantly is to introduce intelligence to the planner. Heuristics, based on the experiences of the Cluster Fct, like visibilities to be taken preferably, reduce the search space for the solver tremendously and speed up the whole solving process. Favoured visibilities are for example Hbr availabilities. In an optimised plan all occurrences of Hbr should be booked by the scheduling tool to achieve the best downlink efficiency. The allocation of Lbr passes should complete the timelines. Furthermore, the solver needs to be extended by functionalities which do not only satisfy the constraints but optimise the whole planning process. In terms of Cluster, this means that the Ssr fill level should not only be kept below 100% but rather kept as low as possible as imposed in the scheduling goals 3.1. Additionally it is of great advantage to guarantee a certain robustness of the plan. Based on heuristics, it is also desirable to implemented strategies to schedule Mspa and power sharing passes. These pass types have not been considered yet. The effect of both pass types have a high potential of decreasing costs for ground station scheduling as they reduce the number of tracking hours with equal data return and therefore increase the efficiency of a plan. Mspa and power sharing passes can be considered as a main driving factor to reduce the tracking hours and costs of a ground station plan. A strategy which is not even yet tested operationally, is combining both pass types which would result in a power sharing secondary Mspa pass. This might increase the opportunities for which Mspa passes can be scheduled and reduce the amount of tracking hours further. A further constraint which has not been implemented yet, is the consideration of the number of command in the on-board Ttq. For this constraint, it is necessary to implement a complex model for the creation of Tc within Apsi. As ground station passes are scheduled dynamically by the framework with a certain flexibility attached to them, the created Tc need to be flexible as well and should be able to move on their timelines. The scheduling of the commands can be considered as the most difficult part and is probably computational very intensive as the number of synchronisations deployed in the domain would increase highly. This feature has the least priority for all future developments, as the constraint is covered already mostly by the necessity to have a ground station pass every 40 h and its implementation can be considered 71

83 Chapter 7. Outlook and Further Work as very time consuming and complex. Once, these tasks are completed, it is necessary to test the tool in an operational environment and analyse the produced plans very carefully. This should reveal possibilities and constraints where fine tuning of the requirements can improve the resulting plans and speed up their generation. This is due to the fact that most constraints are chosen very conservatively, like the margin of 9 min after Aos when the actual Ssr dump starts. In reality, this period is much shorter due to fully automatic commanding of the spacecraft from the automation system. Additionally, it is necessary to find a way of neglecting the dump margins during a fixed pass with a bit rate change in the middle (see fixed passes in ). Furthermore, it has to be evaluated how the relaxation or tightening of constraints may change the outcome of ground station plans. Mostly the behaviour of the planner and how it influences the produced plans should be observed which also leads to a better understanding of how the planner reacts to certain conditions. It might also be useful to be able to change some constraints directly in the scheduling tool, independent from the Ddl file, to force the solver to produce different solutions. For this, it is necessary to define which constraints should be adjustable and within what range. Further improvements and the necessity of new functionalities or features will emerge when the tool is applied in routine operations. New constraints will definitely arise in the following years of Cluster. Their integration should be easy to implement as the scheduling itself does not has to be changed due to the fact that the approach of using the Ddl has been chosen. The source code of the tool s Gui should not require major revision. The development of the scheduling tool based on Apsi is an initiative for automating and simplifying the overall mission operations for Cluster and is just the first step. A lot more improvements concerning not only the scheduling aspect of the Cluster mission but also the execution and reconciliation are planned. From 2015 on, Cluster started to conduct autonomous, fully automated ground station passes. This means that the deployed automation system is responsible for all aspects of ground station communication with the spacecraft not requiring supervision from a human operator. In the process of automating and modernising mission execution, Cluster will start using an electronic logbook system in order to replace the common handwritten logbook. This will also allow the automation system to write log entries automatically during ground station passes. In order to enhance communication and gather information centralised, a discussion platform for reflecting on problems of past passes will be deployed. Seeing these aspects, it will be very interesting to see how the scheduling tool can be further integrated by utilising these technologies. 72

84 Chapter 8. Conclusion Apsi was designed for rapid prototyping and implementation. Even though the tool is not ready to be used in routine operations, it can be concluded that this statement can be confirmed as the design and implementation of the scheduling tool could be conducted in the very limited time span of a 6 months internship at Esoc. This includes the understanding and modelling of all constraints in the Cluster domain using the given modelling languages, as well as the development of the necessary infrastructure to use it, including interfaces from and to the tool as well as the tool itself. The fact that the scheduling tool requires a resource driven solver which needed new components and solving strategies of the framework, can be identified as the main factor for delays. The size of the domain and the necessity for new and tailored solvers in Apsi has been underestimated. As it was only possible to create preliminary plans with the assumption of some simplifications, a final conclusion about the quality of the produced plans can not be given at the moment. But, regarding the results of similar tools based on Apsi and similar frameworks like Europa, it can be assumed that Cluster mission planning will benefit greatly from the usage of the tool. Looking at the key role it takes in the process of ground station pass scheduling, the tool will be further developed at Esoc and brought to a status where it can be used routinely. In the end not only the Cluster mission will benefit from the implementations done, but also the framework itself. Apsi has been extended by further functionalities and features from which other mission will also profit. Experiences gathered during the integration of Apsi in an operational environment should be taken as lessons learnt for the development of future tools. 73

85 Appendix A. Ground Station Plan Evolution and Analysis The ground station plan initially provided to the Cluster Fct is created by Eps. Figure A.1 exemplary depicts such a pass plan for the week from 6 th until 12 th of July Fig. A.1.: Ground station pass plan from 6 th until 12 th of July 2015 created by Eps. It can be seen that multiple scheduling constraints are violated. The most obvious violations are already marked by the constraint checking functions of ClusterWeb. The ground station pass for Clu1 marked with red contains a Tda8 which is not allowed as Wbd is downlinked to Dsn ground stations and therefore the transmitter is not available for Esa operations. The yellow coloured passes of Clu1 and Clu3 do not fulfil the constraint for ground station configuration activities of either exactly 10 min or at least 60 min between two consecutive passes over the same ground station. Furthermore, the minimum pass duration of 1 h is violated multiple times. But, the biggest problem with this pass schedule is that the Ssr fill level is much to high for all spacecraft and reaches especially for Clu3 multiple times its maximum capacity. 74

86 To sum it up, this plan cannot be used for spacecraft operations and requires a major revision, done by the Cluster Fct. This requires heavy manipulation of the plan which can take up to 1.5 to 2 man-days a week. Additionally new constraints and information has to be populated to the database and the plan needs to be adjusted according to the new conditions. The Tda modes are for example not known when the initial plan is delivered to the Fct. Figure A.1 does for example not show any other Tda mode than 4 and 8. Mission planning is done on an iterative basis until a final plan exists and has successfully been conducted. Figure A.2 1 shows the final ground station plan for the same week in July 2015 as in Figure A.1. Fig. A.2.: Final ground station pass plan from 6 th until 12 th of July 2015 created by the Cluster Fct. Besides from two passes (last Kru pass on Clu1 and last Vl2 pass on Clu3) every scheduled pass from Eps experienced either major revision or was deleted from the schedule. Furthermore, numerous new passes had be to be created in order to keep the Ssr fill level low. The presented plan is quite robust with only three moments where the Ssr fill level is increased and the distance between two consecutive passes is about 40 h (Clu2: 8. July, Clu3: 10. July, Clu4: 11. July). Table A.1 shows the statistics for the pass plan of Figure A.2 sorted by used ground stations, the statistics in Table A.2 are sorted by spacecraft. 1 The representation of the Ssr fill level in ClusterWeb has a certain inaccuracy for past plans. Only during ground station passes, ClusterWeb can fetch the position of the record and reproduce pointer from the database. That is why the Ssr has a constant slope between the passes and does not regard the data production rates for the different Tda modes. On Clu4 on the 9 th of July a database error of the pointer position gives a wrong representation of the Ssr fill level during the ground station pass. 75

87 Appendix A. Ground Station Plan Evolution and Analysis Dump Hrs Station Charged Hrs Track Hrs (Hbr) (Lbr) Config Hrs #Pass Msp 37:21:00 28:21:00 21:54:00 04:57: Nno 08:21:00 05:21:00 04:51:00 00:00: Per 19:39:00 15:39:00 09:10:00 05:49: Kru 16:41:22 12:41:22 04:13:31 07:47: Vl2 29:42:41 21:42:41 17:00:41 03:22: Total 111:45:03 83:45:03 57:09:12 21:55: Tab. A.1.: Ground station pass plan evaluation sorted by ground stations for the week of the 6 th of July Dump Hrs Spacecraft Charged Hrs Track Hrs (Hbr) (Lbr) Config Hrs #Pass Clu1 28:34:31 21:34:31 13:06:31 07:18: Clu2 25:05:51 18:05:51 08:55:00 08:00: Clu3 25:44:41 19:44:41 18:44:41 00:00: Clu4 32:20:00 24:20:00 16:23:00 06:37: Total 111:45:03 83:45:03 57:09:12 21:55: Tab. A.2.: Ground station pass plan evaluation sorted by spacecraft for the week of the 6 th of July Due to priority of other spacecraft on Nno, Per and Kru, Cluster ground station passes are mostly booked on Msp and Vl2. This can be observed in Table A.1. The big 35 m satellite dish of the Estrack deep space ground station in Nno allows downlink in Hbr with a smaller signal-to-noise ratio than on the others which results in only Hbr passes on Nno. During the scheduled week, Msp and especially Kru availabilities were fewer than usually due to launch preparation of Eumetsat s Msg- 4 on July 15 th Having a closer look at Tab. A.2, it can be observed that Clu3 is the only spacecraft which was able to conduct all passes in Hbr. This is due to the fact that this is the only spacecraft where power sharing passes are allowed. Two power sharing passes have been booked for Clu3, both on Perth marked by the dashed boxes surrounding the pass. Besides from that the statistics for Cluster 1, 2 and 3 are very similar. Clu4 has a much higher number of tracking hours due to the fact that it produced more data than the others (no Tda2 during the whole week). 76

88 Appendix B. Multiple-Spacecraft Per Aperture Multiple-Spacecraft Per Aperturue (Mspa) has been tested and introduced to mission operation by the Cluster Fct in June This strategy allows to communicate with two satellites at the same time and helps using the ground station resources more efficiently. With this technique it is possible to dump Ssr data from two different spacecraft simultaneously which increases the returned data volume significantly while the amount of tracking hours stays constant. Each ground station has two available Tm chains. During routine passes both chains are connected to one spacecraft for redundancy reasons. This redundancy is lost during Mspa passes. During Mspa operation, each spacecraft is connected to one of the two different chains of the ground station. The primary spacecraft has both uplink and downlink capabilities whereas the secondary spacecraft can only downlink Tm and dump Ssr data (see Figure B.1). The configuration of the primary spacecraft during a Mspa pass does not differ from the configuration of the spacecraft during a routine pass. But as it is not possible to command the secondary spacecraft, the necessary Tcs for initiating the Tm and Ssr dump need to be uploaded to the spacecraft beforehand in form of time-tagged Tc. Mspa passes have the risk that problems on one of the ground station chains, would make a re-dump of the Tm data necessary as no redundancy is available. Fur- Primary Sc (Tm & Tc) Secondary Sc (Tm) Aod Fig. B.1.: Schematic drawing of Mspa. 77