PAZ Mission Planning Facility: Coping with Complexity and Performance through Automated Operations

Transcription

1 SpaceOps Conferences 28 May - 1 June 2018, 2018, Marseille, France 2018 SpaceOps Conference / PAZ Mission Planning Facility: Coping with Complexity and Performance through Automated Operations L. Fernández 1, A. Guarido 2, A. Domínguez 3 and J. A. Tejo 4 GMV Aerospace and Defence, S.A.U., Madrid, E-28760, Spain PAZ ("peace" in Spanish), formerly known as SEOSAR/PAZ, is an X-band Synthetic Aperture Radar (SAR) Spanish mission, in fact a flagship mission of the Spanish Space Strategic Plan GMV has developed the PAZ Mission Planning Facility (MPF), which is the processing element of the PAZ Ground Segment that generates the schedules related to both satellite and ground stations. The many different types of activities to be planned, the fact that some of them have to be planned together, the high number of constraints to be checked during the planning process, the high number of acquisition requests to be processed, as well as the demanding time constraints for schedule delivery and replanning, causes a complex planning process that has to be managed with a high degree of automation. This paper presents the techniques developed in the PAZ MPF facility to cope with PAZ operational concept, to successfully handle the complexity of PAZ planning process and at the same time meet the demanding performance requirements imposed by the mission to the mission planning process. The paper also shows how these techniques contribute to perform various operations in a fully automated manner. I. Introduction Based on the TerraSAR-X platform, PAZ is a dual-use mission (civil/defense) composed of one satellite (PAZ satellite) carrying one Synthetic Aperture Radar (SAR) instrument on board as the primary payload. The main objective of PAZ-SAR instrument is to provide high quality SAR imagery in a variety of sizes and resolution, ranging from medium over wide regions up to very high resolution (e.g. meter and sub-meter). Operational flexibility with multi-mode, multi-polarization and left and right looking attitude is one of the major PAZ system requirements leading to a quite large number of different instrument configurations and antenna beams. PAZ satellite was successfully launched on 22 February, 2018 on a SpaceX Falcon-9 vehicle at Vandenberg Air Force Base in California. After successful Launch and Early Orbit Phase (LEOP), the satellite was handed over to the Ground Control Center located at Instituto Nacional de Técnicas Aeroespaciales (INTA) in Torrejón de Ardóz (Madrid), which is now leading the commissioning phase. GMV has developed the PAZ Mission Planning Facility (MPF) powered by gmvflexplan technology, the GMV generic mission planning and scheduling system. The MPF is the processing element of the PAZ Ground Segment (GS) that generates the schedules related to both satellite and Ground Stations (G/Ss). The MPF is a highly automated system that receives Data Take orders (i.e., requests to acquire an image of a specified area on the Earth surface) of different kind (standard orders, system orders, and health check orders) from different users. These requests are sent to the Instrument Operation (IO) service (CFI developed by the DLR and integrated with the MPF) to get detailed instrument parameter settings for SAR data takes as well as information useful for the planning. The MPF has to include as many as possible of these Data Take orders in the produced schedule, taking into account the constraints of the spacecraft as well as the constraints of the communication scenario. The MPF also receives requests for manoeuvre and Attitude and Orbit Control System (AOCS) maintenance activities and has to include them in the schedule, considering potential conflicts that can arise with other activities. The main output of the MPF is a conflict free schedule, which is a list of satellite activities with execution start times, durations, and parameters. This schedule is sent to the Mission Control System (MCS) which in turn converts it into telecommands and, during G/S contacts, transmits them to the spacecraft via the S-band link. In detail, the schedule embeds the following activities for spacecraft operations: 1 Project Manager, Mission Planning Division, lfernandez@gmv.com. 2 Lead Space Systems Engineer, Mission Planning Division, aguarido@gmv.com. 3 Lead Space Systems Engineer, Mission Planning Division, aldominguez@gmv.com. 4 Head of Division, Mission Planning Division, jatejo@gmv.com. 1 Copyright 2018 by GMV. Published by the American Institute of Aeronautics and Astronautics, Inc., with permission.

2 commands for SAR instrument operations, including: - on-board file handling (allocation and deletion of SAR data files), - SAR instrument activation levels: wake up from sleep-level / go to sleep-level, - SAR data takes acquisition, - SAR data downlink, - on-board memory configuration changes for SAR acquisitions, depending on different instrument modes. commands for switching transmitters on and off for both S- and X-band (the S-band is used for telecommands uplink, as well as for satellite telemetry downlink, whereas the X-band is used for SAR data downlink), commands for S-band telemetry downlink, commands for spacecraft attitude roll manoeuvres in order to enable non-standard SAR instrument orientation for left-looking acquisitions. Some of these activities need to be planned together. For example, the planning of a SAR Data Take (DT) entails the planning of its file creation, its file deletion, its corresponding downlink, the switching between different instrument activation levels, or even the planning of a previous attitude roll manoeuvre (only for the case of leftlooking acquisitions). Moreover, a huge number of constraints (about 60 constraints) between activities of the same as well as different types exist. A few examples are: file creation before DT acquisition, DTs cannot overlap, no more than 10 telecommands per second, daily quota for defense and scientific DT requests, limited resources (satellite on-board memory and number of telecommands to be stored on-board, telecommands uplink size, visibility downlink time, etc.), grouping of file creation or file deletion activities within one command (with a maximum limit for the number of files). Regarding performance, the MPF has to deal with several challenges such as handling a high number of activities (more than 1000 per day) and fulfilling an order deadline of six hours before uplink. In addition, short-order delivery response times of SAR images are demanded. This is the case of emergency requests, which must be processed by the MPF within less than 80 minutes. Therefore, the planning process needs to be reworked frequently. The many different types of activities to be planned, the fact that some of them have to be planned together, the high number of constraints to be checked during the planning process, the high number of acquisition requests to be processed, as well as the demanding time constraints for schedule delivery and replanning, causes a complex planning process that has to be managed with a high degree of automation. Besides, the MPF includes other features required by the mission, namely: usage of different G/S scenarios, management of requests priorities, partial downlink of SAR data. This paper presents the solution developed to cope with PAZ MPF demanding requirements. The presented approach could help in the design of future mission planning systems tackling similar challenges. The paper is organized as follows. The first section briefly outlines the MPF context within PAZ GS. The paper s next section presents the different challenges tackled in the design of the MPF, exposing, for each challenge, its problematic and derived requirements. Then, the solution found to cope with MPF requirements is described. The way in which the developed solution contributes to perform various operations in a fully automated manner is shown in the paper s next section. A final section presents our conclusions. II. MPF Context Figure 1 shows the interactions between the MPF and other PAZ GS subsystems (only the interactions relevant for the present discussion are shown). 2

3 FDS MPF Events MPF AOCS & Manoeuvres MPF Time Corrections N PDGS D PDGS Civilian DTOL Civilian DTSL Civilian MOP Defence DTOL Defence DTSL Defence MOP Unavailability Plan FOCC Pass Plan MOP FOS M&C MPF Data Take Request MCS Pass Plan MCS Schedule Fig. 1 MPF context and main interface flows As seen in the figure, the external systems interacting with the MPF are: Flight Dynamics System (FDS). The FDS system is responsible for the orbital operations of the spacecraft. It provides three different files to the MPF: - MPF Events, containing Ascending Node Crossing (ANX) events and the satellite-g/ss visibilities. ANX events are needed in the MPF to perform conversions from UTC date/time to orbit/anx time and vice versa. Satellite-G/Ss visibilities are taken into account for the planning of all the activities related with telecommands uplink, telemetry downlink and SAR data downlink. - MPF AOCS & Manoeuvres, containing requests for manoeuvre and AOCS maintenance activities. During the planning process, manoeuvres and AOCS activities have preference over any other activity. They have different treatment in the sense that AOCS activities come with a certain time margin to be used in case there are conflicts with other activities, whereas manoeuvres have no time margin at all. - MPF Time corrections, containing the time correction between the real and reference satellite orbit. All MPF inputs are based on the reference orbit and the MPF performs the planning in reference orbit. This file is needed at output file generation time to convert the times of the planned activities to the real orbit time before sending the files to the external systems. Nominal Payload Data Ground Segment (N-PDGS). This system is responsible for the handling of civilian users as well as the processing of the data related to civilian acquisitions. It sends the Civilian DT Order List (DTOL) to the MPF, which contains a set of DT requests from civilian users, each one containing the DT specification. It also receives from the MPF: - The Data Take Status List (DTSL), containing information on the planning and execution status of the requested data takes (e.g. planned, not planned, cancelled, uploaded, etc.). IO TC report Planning Information Data Take Command Set Radar Parameters MCS 3

4 - The Mission Operational Plan (MOP), containing the list of civilian replay 5 activities planned by the MPF. Defence Payload Data Ground Segment (D-PDGS). This system is responsible for the handling of defense users as well as the processing of the data related to defense acquisitions. Its interfaces with the MPF are the same interfaces as those of the N-PDGS but restricted to DT requests from defense users. FOS Monitoring & Control (FOS M&C). This system is in charge of monitoring the subsystems and of routing the data flow between the MPF and the G/Ss and between the MPF and the Acquisition and Routing Facility (ARF). It sends the Unavailability Plan to the MPF, which contains the time intervals where the G/Ss are unavailable for PAZ mission due to maintenance or failure issues. During the unavailability periods, it is not possible to plan any telecommand uplink, telemetry downlink, or SAR data downlink activity. The FOS M&C receives two files from the MPF: - The FOCC Pass Plan, containing the start times and durations of the X-Band and S-Band visibilities. This information is needed by the G/Ss to make the pointing. - The Mission Operational Plan, containing the list of civilian and defense replay activities planned by the MPF. Instrument Operation (IO). The IO is in charge of computing the resources usage and the values of the command and radar parameters for the instrument related activities. It receives from the MPF the DT requests contained in the civilian and defense DTOLs and returns to the MPF, for each DT request: - Planning Information, containing information needed for the planning: time dependencies with previous DT, DT start time, real DT duration, Solid State Mass Memory (SSMM) consumption, number of recorded source packets, TeleCommand (TC) consumption, etc. - Data Take Command Set, containing the command parameters to be uploaded to the instrument to program the DT. Thus, the Data Take Command Set is routed by the MPF to the MCS within the MCS schedule. - Radar Parameters, containing information about the radar echo timing and the antenna imaging mode. Mission Control System (MCS). The MCS is in charge of generating and uplinking the telecommands to the satellite as well as receiving and processing the telemetry received from the satellite. The MPF sends to the MCS the MCS Schedule file, containing the full schedule of instrument and platform activities. The MCS in turn converts these activities in telecommands, uplinks them to the satellite and sends the TC Report to the MPF with the execution status of the activities in the MCS Schedule. With the information in the TC report, the MPF generates the Data Take Status List for the N-PDGS and D-PDGS. The MPF also sends the MCS Pass Plan file to the MCS containing the start times and durations of the S-Band visibilities. This information is needed by the MCS to connect and disconnect the links to the G/Ss. III. Challenges We faced many challenges when designing the system. These challenges are listed in the next table (second column), classified according to different criteria (first column). From each challenge, we derived a set of requirements for the system (third column), each one numerically identified (last column) for traceability in the following discussion. The following subsections discuss in detail each challenge and derived MPF requirements. Table 1 MPF challenges and derived requirements Category Challenge Derived requirement for the MPF Code Performance Fast replanning Centralized DB 1 Automatic ingestion & processing 2 Demanding requirements in terms of processing time and computational load Filtering mechanism for emergency DT requests 3 Centralized DB 1 Automatic ingestion & processing 2 Powerful technology handling a huge number of activities 4 at the same time solving their conflicts in a reasonable amount of time Check and solve different constraints at different stages 5 5 A replay is a downlink activity assigned to a G/S visibility in which many DTs are downlink. 4

5 Category Challenge Derived requirement for the MPF Code Discarded activities not considered in later processing Automatic detection and resolution of conflicts 6 Constraints High number Check and solve different constraints at different stages 5 Related activities Different nature of the constraints to be checked and their resolution policy Connect activities in the system Maximize number of planned activities Flexibility Configurable G/S scenarios implementing a certain logic Calendar Tight development & validation schedule Use a Rules Engine when there is a huge number of activities and significant conditional branching solved by simple rejection or moving some activities in time. Develop specific code for the constraints that follow perfectly defined algorithms that require performing computations in a strict sequence. Relational DB and data model, including planning status for 9 activities Rejection mechanisms 10 Check and solve constraints of related activities in the same stage 11 of the planning process Implement the generation of G/S visibility activities in 12 configurable (i.e., not hard-coded) rules Use existing planning systems or technologies 13 A. Performance In the nominal case, there is a products reception limit of six hours before schedule delivery. However, in contingency cases, a DTOL with a maximum of 10 emergency DT requests (emergency DTOL) can arrive after this time limit and the MPF must process them within 80 minutes. Thus, the system must provide fast replanning capabilities when a DTOL containing emergency requests is received. In order to cope with this requirement, the replanning must start using a previously generated schedule as a baseline and update it based on the new information that has become available. This means that the system must be able to replan (with changes in the inputs) without reprocessing all the data, which implies that: Data produced by the MPF (ingested events, planned activities, schedules, etc.) shall be stored in a centralized DataBase (DB) so that it can be accessed when replanning, not needing to create them from scratch by running the whole processing again. The database shall be centralized, meaning that it shall be used by all the components of the MPF so that the planning process can be resumed at any of its stages. The ingestion and processing of input files shall not wait until the products reception limit is reached. It shall be automatically launched each time a new input file is detected. This way, the information contained in the input files is always processed and available in the system before the planning session starts. This point is particularly critical for the DTOL file, as the IO service is called as many times as number of DT requests present in the file. For the contingency cases, the system shall provide a filtering mechanism to only process the emergency DT requests contained in the input DTOL file. Apart from the fast replanning challenge, the system has quite demanding requirements for schedule processing in terms of processing time and computational load. Regarding processing time, the system must fulfil a schedule delivery deadline of six hours before its uplink. Also, from the computational load point of view, the system must process a high number of activities and DT requests per day (more than 1000 activities and 150 DT requests per day). This led us to detect, apart from the Centralized DB and Automatic ingestion & processing requirements mentioned above, the need for: A powerful technology capable of loading a huge number of activities at the same time and detecting and solving the conflicts between them in a reasonable amount of time. This suggested us the idea to incorporate a Rules Engine in the system. Checking and solving conflicts at different stages during the planning process and not considering an activity in future stages once it is discarded. Otherwise, if all constraints were checked in the same stage, the number of activities and processing time would be high, resulting in an endless process. This could compromise schedule generation as a consequence of the high memory and CPU utilization. Even if constraints were checked at different stages but discarded activities were considered in future stages, the process would be more iterative, looking for a suitable substitute activity. It is therefore necessary to 7 8 5

6 perform the different constraint checks and resolutions in different stages at the cost that discarded activities are not considered anymore. Maximizing automation (i.e., minimizing manual operations). Apart from the above mentioned automatic ingestion & processing requirement, operator interventions shall be minimized as much as possible. This is particularly critical for constraints checking and resolution. It is not feasible that the operator manually checks and solves, for all the activities in the schedule, the nearly 60 different kind of constraints that can be encountered. The system shall therefore implement automatic detection and resolution of conflicts based on pre-defined criteria. Of course the operator shall be able to manually modify the resulting schedule, but once the system has performed most of the work. B. Constraints As mentioned before, there are approximately 60 constraints to be checked by the system. If the MPF were to check all these constraints for all the activities in the schedule in a single-stage planning process or by a single component, the search for a valid solution would become an endless process. It is therefore necessary to check the different constraints and solve encountered conflicts at different stages. As already mentioned, this strategy presents the disadvantage that an activity rejected at a given stage can leave a time slot that could be occupied by an activity rejected in a previous stage for presenting a conflict with it. However, this strategy results in less computational load and processing time, produced by the fact that, as the planning progresses, there are fewer activities to process simultaneously and therefore fewer constraints to check. Another challenge we tackled was the different nature of the constraints to be checked and their resolution policy, which implied that they must be handled by different techniques. There is a first group of constraints that involves significant conditional branching or decision-making (nested ifstatements). This is the case of the constraint DTs cannot overlap. In case of overlap, the conflict is solved by rejecting the DT with less priority. Another example is the constraint DTs cannot overlap with AOCS activities. In case of overlap, the conflict is solved by moving the AOCS activity within a certain time margin and in case the conflict is not solved, the DT is rejected. A third example is the case of time overlap between: file creation activities and start record or stop record activities, file deletion activities and start record or stop record activities. In this case, file creation and deletion activities have flexibility and can be moved in time to solve the conflict. However, start record or stop record activities are fixed at a certain margin before or after the DT acquisition, respectively. The conflict is therefore solved by moving the file creation or deletion activities to avoid the overlap. Rules Engines are the most efficient tools for checking this kind of constraints between activities and solving potential conflicts that may arise between them. There is a second group of constraints that involve different kind of computations (grouping activities, sorting them in time, processing them in a particular order, performing computations from their parameter values, etc.). This is the case of the daily quota for defense and scientific DT requests. For each of these types of requests, there is a maximum allowable number of scenes per day (quota). Then, for these DT requests, the MPF has to group them per 24h period, sort them by priority, go through the list of DT requests by descending priority order, add up for each DT its corresponding number of scenes per day (obtained from the DTOL) and check that the quota is not surpassed. In case the quota is surpassed, the DT is discarded continuing with the next DT request with less priority. Another example is the maximum telecommands size that is possible to uplink (maximum TC uplink size). The MPF has to ensure the uplink of all the activities in the schedule. If the maximum TC uplink size is exceeded, the less prioritary DT requests and related activities must be discarded until the limit is not exceeded. For it, the MPF has to consider: The time available for the schedule uplink, considering the S-band uplink G/S, its visibilities duration, and the allowed uplink time interval. The TC size of each planned activity, which is computed differently depending on the activity: from information provided by the IO service for DT requests, from a given formula for file creation and file deletion activities, and using a fixed value for the remaining activities. The MPF has to add all TC sizes of all planned activities within the schedule time coverage and compare the result with the maximum allowed TC uplink size (uplink time available multiplied by uplink data rate). In case the limit is exceeded, the less prioritary DT requests and related activities shall be discarded until there is no conflict. The checking and resolution of this second group of constraints follows perfectly defined algorithms that require performing computations in a strict sequence. Thus, it is more suitable to fully code them instead of using a Rules Engine. 6

7 C. Related Activities As mentioned before, some of the activities need to be planned together. The most complex case is that of the planning of all activities connected with a SAR DT. The planning of a DT entails the planning of its file creation on SSMM, its acquisition, its downlink in a visibility, its file deletion from SSMM, its sleep levels 6, or even the planning of a previous attitude roll manoeuvre (only for the case of left-looking acquisitions). This issue adds complexity to the system because if one of the related activities is rejected during the planning because it is not possible to solve a certain conflict (e.g., the DT cannot be downlink because there is not enough space available in the visibility), all the related activities already planned must be rejected, allowing the planning of other activities. This requires to: Connect related activities in the system, which introduces the need to: - Use a relational database and relational data model. In particular, both shall consider a planning status for activities that shall inform on whether they have been planned or rejected. This way, at the moment of rejecting an activity, it is possible to know which related activities are already planned and also reject them. - Develop mechanisms to reject all related activities already planned when one of them cannot be planned. Allocate other activities in the time slots left by rejected activities (i.e., maximize the number of planned activities). As constraint checks and resolutions are performed in different stages, this is achieved by checking the constraints of the related activities in the same stage of the planning process. D. Flexibility PAZ mission considers two G/Ss for S-band uplink/downlink and X-band downlink, both located in Spain territory: Torrejón nominal G/S, located in Torrejón de Ardóz (Madrid) and Maspalomas backup G/S, located in Gran Canaria (Canary Islands). In addition, it considers a third potential G/S located in a Polar region (Polar G/S) to enhance S-band and X-band downlink. It is required that the MPF is able to perform operational schedules using different predefined G/S scenarios selectable by the operator. In the MPF context, a G/S scenario is defined by: The S-band uplink G/S. The downlink G/S or G/Ss for S-band and X-band. Downlink can be performed in a single G/S, in a particular combination of two G/S and even in three G/Ss. In case of downlink in two or more G/Ss, the main and secondary G/Ss are also defined. This is done for the case of coverage overlap between G/Ss, to indicate that, in the overlap time span, downlink takes place in the main G/S. Specification of G/S for defense DT downlink. Moreover, it is required that, although configured for a certain predefined set of G/S scenarios, the MPF allows the inclusion of additional G/Ss and G/S scenarios with minimum configuration changes. The selected G/S scenario is used by the MPF to generate all the S-band/X-band activities related with G/S visibilities (e.g. switch transmitter on/off, start downlink, etc.) following a certain logic that depends on the G/Ss combination (e.g., if two G/S visibilities overlap, there is no switch on/off activity in the overlap region). The fact that such G/S scenarios must be configurable in the system (i.e., not hard-coded) and must implement of a certain logic for the creation of G/S activities, suggested us the idea of implementing this logic in configurable rules and incorporating a Rules Engine that interprets such rules. E. Calendar The development and validation of planning systems is a costly and time-consuming process that represents a significant risk due to the criticality and operational relevance of these systems. For the case of the MPF, the development and validation schedule was quite tight. The system had to be developed, unit tested and integrated in 10 months and had to be validated and accepted in eight months. With this schedule constraints, we had to minimize somehow development and validation efforts so one important requirement for the system was to use existing planning systems or technologies, preferably operational. 6 If the inactivity time between the DT and its preceding and/or subsequent DT is greater than a certain threshold, the instrument is powered up before the DT and/or powered down after the DT following different sleep level transitions that depend on the inactivity time. 7

8 IV. Design Solution With the goal to reduce planning systems development and validation costs, GMV has developed in recent years a generic mission planning and scheduling system called gmvflexplan. The intention was to avoid the implementation of rigid elements for a specific mission that would prevent their reuse in other missions. Thus, gmvflexplan provides fully configurable mission planning and scheduling system capabilities in the form of generic components that serve missions as basis to build their planning systems. gmvflexplan provides standard functionality that missions can extend, if needed, to meet their requirements. For a mission that uses gmvflexplan, customization and new developments are sometimes required. Its flexibility supports complex missions from earth observation to scientific interplanetary and from single to multi-platform fleet of spacecraft. It is fully operational in different types of missions ([1], [2], [3], [4], [5], and [6]), so the system is quite stable and robust. Besides, as will be discussed below, some of its components already cover many of the requirements identified in previous sections, only needing minor adaptations in most of the cases. Our preference for the Use existing planning systems or technologies requirement (Code equal to 13 in Table 1) was therefore gmvflexplan. Figure 2 shows a first functional breakdown of the MPF in a set of components. gmvflexplan use is indicated by means of a color code: components depicted in red are used from gmvflexplan with no modifications, white components are used with modifications while the black ones have been fully implemented from scratch. Database Mission DB Process Management Component PM MEP SG Rules Tool Access Component AM Planning & Scheduling Components TEG CR Support Components CS PIC DM SE Interface Component EIM HMI HMI Planning Rules TEG rules SG rules CR rules Fig. 2 MPF high-level view The different MPF components are presented below, making special emphasis in those that implement the requirements identified in the previous section. Numbers within curly braces (e.g. {1, 2}) next to a component name refer to the last column of Table 1, this way providing a trace between each requirement identified and the MPF 8

9 component that implements it. The Use existing planning systems or technologies requirement (Code equal to 13 in Table 1) is mapped to all MPF components that use gmvflexplan. As shown in Fig. 2, the MPF is split into the following components: Mission Database (Mission DB) {1, 9}: in charge of storing and providing data to the different MPF components. In this DB, everything produced during the planning process is stored (e.g. input events ingested, generated activities, or executable schedules) so that it is not necessary to create them each time they are needed. It is a centralized database in the sense that all the data exchange flows between the components of the MPF make use of it. This way, the planning process can be resumed at intermediate stages. It is also a relational database so that it efficiently implements connections between related activities, making it possible for the different components to search for activities related with a given one. For example, it allows managing the planning status of related activities, updating it at different stages. Mission Environment Preparation (MEP): in charge of configuring the MPF for the mission by defining the necessary events, resources, activities, and rules and storing them in the Mission DB. Access Manager (AM): in charge of handling the operator login to the MPF and providing the means to allow starting individually some of the MPF components. Human Machine Interface (HMI): graphical interface in charge of supporting the operator interaction. Process Monitor (PM) {2}: in charge of supervising the execution of the different processes, being aware of their running status, and controlling the unmanned launching of automatic tasks such as the ingestion and processing of input files. External Interface Manager (EIM): in charge of processing the different input files received from the external entities and also in charge of creating the MPF output files. Rules Tool {4, 7, 12}: in charge of providing a Rules Engine (namely Drools Expert, [7]) capable of evaluating rules as requested by other components. The component also provides a specific graphical editor that allows writing rules expressed in the Drools Rule Language (DRL), which is inherent to the Rules Engine. As indicated in the figure, the Rules Tool is used by three components: TEG, SG, and CR. Thus, there are three kind of predefined rules: TEG rules, SG rules, and CR rules. Tailored Events Generator (TEG) {5, 6, 11}: in charge of generating a first set of candidate events for the schedule and implementing a first batch of constraints checks and resolution. The events produced by the TEG component are called TEG events, and are just activities in a preliminary state, with much less information than the final planned activities. TEG processing is reduced to two main sequential steps: - TEG rules ({7, 12}) processing. TEG rules are concerned with activities that have no flexibility at all in time (i.e., there is no degree of freedom to be taken into account to solve any conflict encountered). These activities are: DTs, G/S visibilities, G/S unavailabilities, and manoeuvres. The following constraints between these activities are checked by TEG rules: DTs cannot overlap (DT vs. DT), manoeuvres cannot overlap with DTs (manoeuvre vs. DT) or downlink activities (manoeuvre vs. G/S visibility), and G/S unavailabilities cannot overlap with downlink activities (G/S unavailability vs. G/S visibility). For the particular case of conflicts between downlink activities (i.e., visibility activities) and manoeuvres or G/S unavailabilities, it is necessary to specify the G/S scenario to be considered. This is achieved by selecting a specific set of TEG rules corresponding to the G/S scenario. Manoeuvres and G/S unavailabilities have precedence, so other activities overlapping with them are rejected. In the case of overlapping DTs, the conflict is solved based on DT priority. - Several TEG coded checks related with DT activities ({8}): determination of nominal and peak orbits 7 to be planned, discarding by priority the DTs that surpass the maximum orbit allowed limits, daily quota check for defense and scientific DT requests, and many others. Planning Inputs Customization (PIC): in charge of configuring the events that will be taken into account in the planning process. Schedule Generator (SG) {3, 12}: in charge of generating the resulting schedule activities in the form adequate for the output files. These activities are created from the events produced by TEG. Due to the huge number of activities involved, this generation is performed by means of rules (SG rules). For the generation of S-band/X-band G/S visibility related activities, it is necessary to specify the G/S scenario to be considered. This is achieved by selecting a specific set of SG rules corresponding to the G/S scenario. 7 A nominal or peak orbit is a 95 minutes time window in which the overall duration or number of DTs acquired within it is below or exceeds a certain limit, respectively. 9

10 There is also a specific set of SG rules whose selection allows filtering and processing only the emergency DT requests contained in the input DTOL files. Conflict Detection & Resolution (CR) {5, 6, 10, 11}: in charge of implementing a second batch of constraints checks and resolution involving some DT activities, namely overlaps between: - file creation/deletion activities and start record/stop record activities, - DTs and AOCS activities. To solve these conflicts, there is some flexibility in some of the conflicting activities, which can be moved in time within a certain margin. As conflicts are solved by moving activities, all of them have to be checked again after any change, making the CR process iterative. Like TEG rules checks, CR checks involve significant conditional branching and have been therefore implemented in rules (CR rules, {7}). Downlink Manager (DM) {5, 6, 8, 10, 11}: in charge of computing the downlink schedule and performing the last batch of constraints. After SG and CR processing, there is a first set of DTs created in the schedule. The DM computes their corresponding downlink schedule in the form of replay or partial replays. While a replay contains many DTs, a partial replay just downloads a set of segments of a single DT. Partial replays are created when there is not enough time in a G/S visibility. The DM also performs many checks involving DT related activities: replays, partial replays, sleep levels, etc. Some of these checks are: available downlink time in the G/S visibility, available on-board SSMM, maximum TC uplink size, maximum number of on-board TCs, maximum limit for the number of files to be created in a single file creation command, and conflicts between start record/stop record and start replay/start partial replay. DM checks are fully coded because they involve well defined algorithms, each one performing specific computations in a strict sequence. Moreover, as DTs have to be downlink by priority order and there are many DT related activities, the DM processing is in a DT by DT basis and in descending priority order. Thus, all checks are performed for each DT: whether it can be fully or partially downlink in a visibility, whether it can be stored in on-board SSMM, whether its file can be created and many other constraints. In case the DT is rejected, all its related activities are rejected. Schedule Execution (SE): in charge of displaying the execution status of the planned activities. Common Services (CS): a library of common functionality shared by all the components. V. Operational Concept Before using the MPF operationally, it is necessary to define in the system all the elements (events, activities, resources, etc.) necessary for the planning activity. This is considered a one-off task that is performed off-line during the mission operations preparation phase of the mission. System re-configuration is not expected to be needed during nominal routine operations. Once the MPF is configured for the mission, it can be used for nominal operations. The MPF nominal planning cycle is outlined in the sequence diagram of Fig

11 PM EIM IO TEG Rules Tool PIC SG CR DM HMI ingest & process() get planning info() start TEG process() select G/S scenario() process TEG rules() TEG coded checks() create timeline of events() generate conflict free schedule() select G/S scenario() process SG rules() transfer output files() Save schedule as executable() get command parameters for DTs() generate output files() process CR rules() Fig. 3 MPF nominal planning cycle start CR process() start DM process() DM coded checks & compute downlink schedule() A. Ingestion and Processing of Input Files The mission planning process starts with the ingestion and processing of input files ( ingest & process ). This is automatically triggered by the PM component for each file detected in the input directories. The PM component is constantly polling the input interfaces reception directories for new files. In case a new file is detected, the PM automatically triggers its ingestion and processing (no operator intervention needed). For the particular case of the DTOL file, the IO service is called for each DT request contained in the DTOL ( get planning info ), in order to get certain information needed for the planning (time constraints between the DTs, SSMM consumption, TC consumption, etc.). B. TEG Processing Then, the operator starts TEG processing and is prompted to select the specific set of TEG rules that correspond to the G/S scenario ( select G/S scenario ). After this, TEG rules processing starts, checking conflicts as colliding DT requests solved by priority or a DT request colliding with a manoeuvre, followed by several TEG coded checks. C. PIC Processing From the PIC component, the operator prepares the timeline of events ( create timeline of events ) for the forthcoming schedule generation process. In the PIC component, the operator can create events from scratch, edit existing events, or exclude/include events from/in the schedule time interval. D. Conflict Free Schedule Generation Then, the operator starts the conflict free schedule generation process ( generate conflict free schedule ). Firstly, the operator is prompted to select the specific set of SG rules that correspond to the G/S scenario ( select G/S scenario ). Secondly, SG rules processing starts and some of the activities to be included in the schedule (e.g. S-band visibility activities, X-band visibility activities, DTs, etc.) are generated from TEG events. Thirdly, CR rules processing starts and a second batch of constraints is checked. Lastly, the DM component computes the downlink schedule and evaluates the third batch of constraint checks (e.g. limited resources such as on-board SSMM). If 11

12 conflicts are encountered during CR or DM processing, they are reported and tried to be solved automatically by the system, through a predefined conflict resolution policy. In case it is not possible to automatically solve a conflict, the schedule is marked as in-conflict and the operator shall solve the conflict manually. E. Output Files Generation and Transfer If the obtained schedule is a conflict free one, the schedule can be saved as executable, meaning that the schedule activities and their time tags are frozen. This automatically launches the generation of a first version of the output files from the executable schedule. Files are generated by filtering the schedule activities according to the defined output interfaces. In order to get the command parameters for the DT activities (included as part of the MCS Schedule file), the IO service is called for a second time for each planned DT ( get command parameters for DTs ). In this call, detailed instrument parameter settings for SAR DTs are obtained from IO (Data Take Command Set) as well as Planning Information and Radar Parameters. After generating the output files, the operator can transfer them to the corresponding external subsystems. F. Relevant Design Issues In order to get a conflict free schedule in a reasonable amount of time, the planning process has to be as much automated as possible. As can be seen, TEG, CR, and DM components implement automatic detection and resolution of conflicts based on pre-defined criteria implemented in the form of configurable rules or code. There is also automation in the ingestion of input files and the generation of output files. Manual operations are therefore minimized, being limited to the following operations: Starting of TEG process (only necessary if new/updated inputs are received). Selection of sets of rules based on operational scenarios. Configuration of events in PIC (optional). Starting of conflict free schedule generation process. Solving conflicts (only if the resulting schedule is in-conflict ). Saving the schedule as executable. Transferring output files. One important aspect to mention is that the current architecture supports replanning, understood as an iteration of the planning process triggered by the reception of new or updated input data (DTOL file, MPF Events, etc.). This is achieved thanks to the Mission DB, which stores everything ingested or processed. When new or updated input data is received, it is automatically included or updated in the Mission DB, respectively. For the case of replanning triggered by the reception of an emergency DTOL, although the same steps than in the nominal planning cycle are followed (Fig. 3), the computational load is reduced. The 10 emergency DTs contained in the emergency DTOL are ingested ( ingest & process ) and then processed in TEG, together with all input events already existing in the Mission DB. Afterwards, upon selection of the emergency SG rules, only the activities corresponding to the 10 emergency DTs are generated ( process SG rules ), which are further processed by CR and DM together with all the activities existing in the Mission DB within the schedule time period. As can be seen, conflicts are checked and solved at different stages during the planning process, namely by TEG, CR, and DM components. TEG rules processing is performed in first place. All candidate activities are loaded in the system and all possible overlaps between them are checked, making extensive use of nested if/then statements. This processing is however quite fast because it is performed by a Rules Engine and there is no degree of freedom to solve the conflicts encountered. As a result, some activities are rejected from the beginning of the planning session, reducing computational load and processing time in subsequent stages. Iterative constraint checking and resolution is left for future stages (CR and DM processing). It is also important to mention that CR and DM components incorporate mechanisms to reject all related activities already planned when one of them cannot be planned. This is done using the relations between activities implemented in the Mission DB. Within TEG, CR or DM processing, once a DT is discarded, it is not considered in future stages of the planning session. As already mentioned, we could have tried to include the DTs rejected in TEG or CR in future stages (CR or DM, respectively) if the conditions that produced the conflict were no longer met due to new rejections. More specifically, as DM does not reject AOCS activities, we could have tried to include in DM the DTs rejected by TEG rules processing (overlapping DTs) or by TEG coded checks (for surpassing certain limits) if the conditions that produced the conflict in TEG were no longer met due to a DT rejection in DM. Although giving slightly better results, we decided not to implement this strategy in order to save computational cost. 12

13 VI. Conclusion This paper presents the different challenges we have faced to develop the MPF of PAZ mission as well as the key design decisions made to address them, namely: Use of gmvflexplan. Usage of a Rules Engine. Maximization of automation. Checking and solving of different constraints at different stages. Checking and solving of constraints of related activities in the same stage of the planning process. Checking and solving of constraints by different methods. Not considering discarded activities in later processing. The result is a highly automated and extremely efficient system, capable of checking all the activities in the schedule against nearly 60 constraints and performing fast replanning in contingency cases. For future missions demanding similar requirements, we intend to develop efficient methods for finding, once an activity is discarded, a suitable substitute activity from the list of previously discarded activities. We also plan to incorporate a solver mechanism in gmvflexplan to handle optimization problems. Acknowledgments We would like to thank those involved in the PAZ program at INTA who have contributed to the definition and development of the MPF. In particular, Ms. Eva Vega Carrasco, Ms. Nuria Alfaro Llorente, Mr. Marcos García Rodríguez and Mr. David Modrego Contreras. References [1] Tejo, J. A., Pereda, M., Veiga, I., Chamoun, J. P., Garcia, G., and Beech, T., "flexplan: An Operational Mission Planning & Scheduling COTS Used Internationally, Proceedings of the 5th International Workshop on Planning and Scheduling for Space, Baltimore (USA), [2] Tejo, J. A. and Colmenero, F., "flexplan Deployment of the Mission Planning System for the SMOS mission, Proceedings of the 7th International Symposium Reducing the Costs of Spacecraft Ground Systems and Operations (RCSGSO), Moscow (Russia), [3] Chamoun, J. P., Kim, J., Beech, T., and Saylor, R., "Mission Planning and Scheduling for the Lunar Reconnaissance Orbiter, SpaceOps 2008 Conference, SpaceOps Conferences, (AIAA ) doi: / [4] Tejo, J. A., Garrigues, A., and Arregui, J. P., "Planning the operations for Sentinel-1 satellite: how to fit a complex puzzle, SpaceOps 2014 Conference, SpaceOps Conferences, (AIAA ) doi: / [5] Kavelaars, A. T., Gregory, S., Garcia, G., Talon, C., Barnoy, A. M., Greer, G., Williams, J., and Dulski, V., "Centralized Mission Planning and Scheduling System for the Landsat Data Continuity Mission (Landsat 8), SpaceOps 2014 Conference, SpaceOps Conferences, (AIAA ) doi: / [6] Pereda, M., Navais, P., and Tejo, J. A. Sentinel-3 operations: implementing plans based on satellite s position, SpaceOps 2016 Conference, SpaceOps Conferences, (AIAA ) doi: / [7] Drools Expert User Guide website, URL: [retrieved 17 April 2018]. 13