1

EMS: A Management and Scheduling System for the ESA Tracking Network

M. Niézette *, M. Götzelmann † VEGA, Darmstadt, Germany

and

G.P. Calzolari ‡ European Space Agency, European Space Operations Centre, Darmstadt, Germany

The ESTRACK Management & Scheduling System (EMS) is a key new component of the ESA Ground Segment that supports efficient management of the ESA Tracking Network (ESTRACK), and integrates the interfaces required to support cross-support and interoperability between ESA and other Agencies or operators. This paper describes the new management and scheduling operational concept supported by EMS, and presents the benefits of the new system to ESA and non-ESA missions, together with the constraints on the mission organization introduced by the interface to EMS. It then concentrates on the planning component of EMS, providing examples of network service allocation for existing ESA missions, and explaining how ESA’s software re-use policy is being instrumental to ensure a timely cost-effective implementation of the system, based on the re-use of the design and code from three different sources.

I. Introduction STRACK, the European Space Agency (ESA) tracking network (see Figure 1), comprises all the ESA facilities deployed around the world in order to provide the tracking services required by ESA. This includes ground

stations, communications and control facilities. The evolution of the network in size, capability and complexity, coupled with the constantly increasing load of the network in a context of growing interoperability between agencies and network service providers, has led to the emergence of a new ESTRACK network service management operational concept.

In the past ESTRACK ground stations were almost exclusively dedicated to given ESA missions, and operated locally by the ground station staff with practically no systems between the ground stations and the control system (only communications lines when the operations centre was not co-located on the ground station site). The network management and scheduling systems were designed in accordance with those principles, and planning performed manually at the scheduling office. Ground stations were scheduled as directly requested by the mission as exclusive users of the facilities.

Stations are now remotely operated on a routine basis. They are supporting multiple missions, within and outside ESA. The requests from the users are evolving from direct request of specific facilities to more generic tracking service requirements.

This new network management and scheduling operational concept is supported by the ESTRACK Management & Scheduling System (EMS), a suite of applications supporting automated planning and scheduling, as well as global monitoring and coordination of the ESTRACK network.

This paper will introduce EMS and its components, and discuss the impact of the system on ESTRACK’s client ESA and non-ESA missions.

* Head of Mission Planning Systems Group, VEGA Aerospace Division, Robert-Bosch Str. 7, 64293 Darmstadt, Germany. † Principal Consultant, VEGA Aerospace Division, Robert-Bosch Str. 7, 64293 Darmstadt, Germany. ‡ Technical Officer, OPS-GI Division, European Space Agency, ESOC, Robert-Bosch Str. 5, 64293 Darmstadt, Germany.

E

SpaceOps 2006 Conference AIAA 2006-5547

Copyright © 2006 by VEGA Group PLC. and the European Space Agency. Published by the American Institute of Aeronautics and Astronautics, Inc., with permission.

2

Figure 1. The ESTRACK Network

II. ESTRACK Management & Scheduling Concept The new ESTRACK network management and scheduling operational concept introduces a new approach in the

way missions handle the allocation of ground facilities, and monitoring and control of the facilities.

A. Interface to the Missions The interaction between the mission and EMS and its impact on the planning cycle of the missions is at the core

of the problematic of the EMS. With the current approach, the interface between the scheduling office and the missions is limited in scope. The

allocation of facilities to missions is based on very static allocation schemes that do not leave much freedom in the way the stations are allocated to the missions. The allocation schemes are also rather simple, as they have to be used to perform the network planning manually. The missions can therefore predict the scenario of allocation of the facilities from the simple allocation schemes and the facility (un)availability profiles, and use it for their own planning.

With the new approach, the allocation of facilities to missions is dynamic. It varies with the context, and cannot be accurately predicted by the mission.

The new concept therefore requires a more complex mechanism of interaction between the missions and the ground facility scheduling, where the missions have to be informed on a regular basis about the evolution of the allocation plan.

The mission interfaces to the scheduling office at two levels: • Before introduction of the mission to ESTRACK, the mission requirements in terms of network support

must be provided to EMS and formalized in a way that can be automatically processed

• During the lifetime of the mission, EMS will provide regularly the mission with network service allocation plans implementing the mission requirements

Kourou, French Guyana

Kiruna, Sweden

Redu, Belgium

Cebreros & Villafranca, Spain

Malindi, Kenya

New Norcia & Perth, Australia

Maspalomas, Canary Island,

Spain

3

EMS must therefore include a model of both the mission requirements (mission model) and the network capability (facility model), and support a protocol through which the mission can interact with EMS during operations.

B. User Services and Operational Services The definition of an automated approach to planning and scheduling of ESTRACK requires clarifying the type

of services that can be requested by the client missions and the type of services that are supported by the network. The operations requested by the client missions are typically expressed at a higher-level of abstraction than the

ones provided by the network. Their implementation requires combinations of network services. The operations can therefore be hierarchically decomposed from top-level services abstracting the needs of client

mission to low-level services that can be compiled into executable commands that drive the facilities. The former are referred to as to User Services, and to the latter as to Operational Services.

In the following sections, we will introduce the ESTRACK Management & Scheduling System (EMS), and show how it supports the operational concept described above.

C. Centralized Generation of Facility Schedules The schedules that control the ground facilities, and more specifically the ground stations, are currently

generated and transferred to the stations by mission-specific software, possibly after merging of similar mission-specific schedules, as it is the case for the ERS and Envisat schedules produced for the Kiruna station. Schedules are not frequently provided, although all stations provide a schedule execution capability. Instead, control procedures are often invoked manually either on a remote or local operator position.

In the new approach, the generation of facility schedules is decoupled from any mission-specific software, and generated by EMS on a regular basis for all facilities and all missions, based on the network management plan.

The centralized approach, in addition to being an EMS service available to all missions at no extra-development cost, ensures global consistency of the generated schedules and better exploitation of station capabilities.

D. Network Monitoring and Management ESA is operating a steadily increasing part of its ground station network remotely from its central Ground

Facilities Control Centre (GFCC) at the European Space Operations Center (ESOC) in Darmstadt, Germany. Remote monitoring and management is nevertheless performed separately for each station from a dedicated

operator position. The new approach will lead to monitoring of the network as a whole, with capability of global monitoring, and some level of co-ordination between facilities, when more than one facility is involved in providing a service.

EMS will provide centralized online management functions required to support non critical or routine phases of the missions. This includes downloading of schedules generated by EMS, monitoring of service provisioning and schedule execution, schedule control, and coordination of facilities. The monitoring functionality will include a synoptic view combining the plans as generated by EMS, and information feedback by the stations, showing the evolution of the plans execution.

E. Cross-Support Cross-support from ground stations under control of external agencies, and to non-ESA missions is also

integrated in the EMS concept. About one fourth of the ground stations routinely supporting ESA mission are outside the core set of ESTRACK ground stations, and the number of non-ESA mission using ESTRACK facilities keeps growing. The level of cross-support in both directions is expected to increase even further in the future, and a clear concept is required in order to provide a standard set of procedures that can accommodate these requirements.

EMS plans all ground support for ESA missions. As such it acts as a single point of contact with the external providers of ground services (NASA DSN, etc.) on behalf of the missions. For external missions, EMS provides the same interface as for ESA missions using suitable interface adaptors where necessary.

4

III. ESTRACK Management & Scheduling System (EMS)

A. EMS Process Model

Figure 2. EMS Process Model

The process model of Figure 2 emphasized the three interfaces of EMS. 1. Off-line interface with the EMS User, i.e. the missions that require the network services of ESTRACK, for

the allocation of network services. This interaction takes place at two levels: • At mission preparation, a mission agreement is established with the mission, which specifies the

network service allocation requirements of the mission;

• During operations, EMS provides the mission with network service allocation plans, and support a protocol though which the mission can interact with the proposed allocation plan within predefined limits

2. Off-line interface with non-ESA agencies for cross-support agreements and provision of network services 3. On-line interface for the remote monitoring and coordination of the ESTRACK facilities, primarily based on

the execution of operations schedules automatically generated by EMS for the automatic and/or manual operations of the facilities.

B. EMS Components The EMS operational concept requires supporting three core functionalities: 1. Automated generation of the ESTRACK network service allocation plan (the ESTRACK Management Plan

– EMP) by a planning tool, therefore increasing the number of allocation scenarios that can be considered by the scheduling office, and improving the reaction time of the scheduling team if emergency re-allocation is required. This must also enable cross-support for external users to request ESTRACK network services, and for ESA missions to request support of external service providers via EMS.

2. Automatic generation of executable schedules of operations for the ESTRACK facilities on a per-facility basis directly from the EMP, therefore ensuring consistency of the plan and the scheduled operations, and the self-consistency of the facility schedules.

3. Remote monitoring and control at network level of the facility schedule execution with respect to the EMP.

EMS

Planning Process Interaction

with Users

EMS Users

Interaction with External

Providers

Non ESA

Agency

Online

ESTR

ACK

Mgnt

ManagedFacilities Ground

Stations NMS

5

In order to support this functionality, EMS comprises three major components, which are loosely coupled and can be operated independently to a large extent:

1. The ESTRACK Planning System (EPS), which generates automatically network service allocation plans according to the requirements of the missions

2. The ESTRACK Scheduling System (ESS), which coverts the allocation plans generated by EPS in schedules that can be executed automatically or manually at the ESTRACK facilities

3. The ESTRACK Coordination System (ECS), which ensures the coordination of the network service allocation at run-time

The components of EMS in their operational context are depicted in Figure 3.

EMS

File Server

ES

TRA

CK P

lanning S

ystem

ESTRACK Scheduling

System

ESTRACK Coordination

System

Planning Products

ESTRACK Ground Station

Communications Network

Management

Mission Operations

Centre

EM

S U

ser Flight

Dynamics

Mission Planning

External Provider (scheduling office)

Proxy

Format

Converter

1

2

6

7

5

4

Planner MMI

Online MMI

EMS Operator Positions

1

3

SMF

Scheduling Products

Legend 1 Submission of mission requests and dynamic mission defined data (event files, planning constraints)

Retrieval of the ESTRACK Management Plan (EMP) and transient plans 2 Transmission of schedules and/or service instance configurations

Note: Schedules are transmitted to Communications Network Management in a human readable form. 3 Output of relevant portions of the ESTRACK Management Plan;

Input of plans received from the external provider 4 Interface depending on the external provider,

for DSN includes submission of the long term request and reception of SAF and SDS 5 Transmission of service instance configurations 6 Online service provision monitoring, schedule control, and coordination of facilities 7 Operational status information exchange via an SMF service Interface

Figure 3. EMS Components

6

C. EMS Internal Model

1. Mission Model In order to plan and provide network services to

the missions, the EMS relies on a mission model, which includes a formalization of the mission network service requirements.

This formal representation of the mission requirements is provided as a set of User Services to be implemented, each of which includes two main components: one or several alternative definitions for the network service groups required by the missions, and standing orders specifying when and under which constraints these service groups shall be provided.

The operations to be planned are decomposed hierarchically from top-level operations abstracting the needs of client mission to low-level operations that can be compiled into executable commands that drive the facilities.

At the top of the hierarchy we have the User Service, which represents the abstraction of a service that can be requested by a client mission. User Services are typically mission-dependent, as they include all characteristics that are needed by the mission in terms of the content of the passes.

At the lowest level of the hierarchy we have the Operational Services, which represent abstractions of services that are provided by the facilities. The Operational Services are mission-independent, although their availability at a facility is constrained by the availability of the mission configuration profiles, which represent the facility configuration corresponding to specific spacecraft modes, and are therefore limited to a set of missions.

The operational services can be combined with constraints to define a User Service. A User Service can have several alternative definitions, representing for instance degraded modes of the service, which can be used to ensure a minimal implementation when the resources required for the nominal implementation of the service are not available.

2. Facility Model

The provider Facilities are constituted by all the elements required for the support of User Service requests to the network. This includes Ground Stations but also Operations teams, Communications Lines, Network Interfaces Systems, etc. External provider facilities are also considered, such as DSN stations, as EMS will act as an interface between ESA missions and the external provider scheduling office.

For each facility the low-level schedule of Operational Service calls generated by EMS is translated into the relevant Monitoring and Control messages that can range from scripts and timelines for automatic execution to operational instructions to the operations team. For non-ESTRACK provider facilities the Operational Service is translated into a Support Request to the externally managed facility, according to its policies, rules and formats. This concept is applicable for both automated and manual operation of the facility.

Mission 1

Mission 2

Optimal Pass 1

Nominal Pass 1

Degraded Pass 1

Telecommand Uplink

Telemetry Reception

Shadow Tracking

Telemetry Recording

Ranging

Off-line Telemetry Retrieval

Facility 1

Optimal Pass 1

Nominal Pass 1

Degraded Pass 1

Facility 2

Facility 3

Missions User Services Operational Services Facilities

Figure 4. Relationship between Missions, User Services, Operational Services, and Facilities

Front End Resource

Return Link Signal Processing Resource

Forward Link Signal Processing Resource

Telemetry Backend Resource

Telecommand Backend Resource

Ranging Resource

Space Link

Mission C

ontrol System

Figure 5. Ground Station Resource Model

7

Table 1. ESTRACK Operational Services Service Type Description / Remarks

Telecommand Uplink Up-linking of telecommands either via the CLTU or via the FSP service depending on the specified SLE service

Telemetry Reception Reception of telemetry and provision of the specified SLE services, if applicable

Telemetry Recording Recording of telemetry for later retrieval; this service depends on the service "telemetry reception"

Ranging Execution of ranging and Doppler measurements and recording of measurement results for later retrieval.

Online Telemetry Transfer Completion

Transfer of online telemetry to the user after the end of the pass for the online complete delivery mode. This activity is defined as a separate service as it only requires telemetry backend equipment and the station might support a pass of a different mission concurrently.

Offline Telemetry Retrieval Retrieval of recorded telemetry by the mission either via an SLE transfer service in offline delivery mode, File Transfer transfer service or via FTP.

Radiometric and Pointing Data Retrieval

Retrieval of recorded Ranging, Doppler, and Meteorological data and of Antenna Pointing Values by the mission

Ranging Calibration Calibration of the ranging equipment

Shadow Tracking Auto-tracking on the spacecraft's downlink signal (without telemetry or telecommand services) in order to validate the accuracy of the orbit prediction.

Radio Science Measurements Tracking of the spacecraft and reception and transmission of an un-modulated carrier to perform radio science experiments

Data Flow Test Execution data flow tests before a spacecraft pass with simulated telemetry; data flow tests are end-to-end including the mission control system.

Simulation Service Operating the station with test loops and simulators to support countdown simulations and dress rehearsals.

The Operational Services provided by a facility rely on the use of equipment provided by the facility. The

availability of an Operational Service at the Facility depends therefore on the availability of the equipments. The capability to provide Operational Services concurrently at the Facility is represented in a resource model of the Facility, which provides an abstract view of the available equipment.

The abstract resources that have been identified in the case of Ground Station Facilities are illustrated in Figure 5.

Each Operational Services is constrained by requirements on these abstract resources, in a pattern including temporal dependencies between the resource requirements.

IV. ESTRACK Planning System

A. ESTRACK Planning Concept The EPS provides central planning of the

usage of the complete ESTRACK ground station network – and ground station resources as provided by other agencies – for all missions using these facilities.

In concept, there is a single, continuously evolving plan (the ESTRACK Management Plan, EMP) which stretches arbitrarily far into the future. Segments of this plan are created or updated and, if successful and conflict free committed to the EMP.

The EMP is constantly updated by input sent by the user missions (events, refinement requests, commitment requests, etc.) and by the results of planning sessions. Planning, as depicted in Figure 6, is a cyclic process that can have a multitude of iterations on each level. In fact the number of iterations between the EPS and the user missions is only limited by the deadline set for the

ESTRACK Planning System

Missions

FDS

Event File

Plan View

Order Refinement

Request

Commitment Request

Session Refinement

Request

Plan View

Time Frozen

EMP Seg.

Plan View

Figure 6. The ESTRACK Planning Process

8

schedule generation of a segment of the EMP. A synchronization of the data exchange between the EPS and all user missions may decrease the number of planning cycles and increase the effectiveness of the overall system. However this may be defined through procedures and does not affect the EPS design.

Figure 6 shows in detail how the planning process starts with the reception and preparation of event files from the missions and its flight dynamics systems. From this point on, the figure depicts an inward directed spiral, where the time points inwards and the maturity of the EMP also increases on the inwards direction. On updates to event files the cycle can be restarted at this level. The presence of event files allows for a first planning session and an update of the EMP. This will be about three months before freeze. Plan views are created as defined by the missions and made available to them. The missions can now send order refinements about two weeks before freeze. Upon reception of a standing order refinement request, the EPS may perform a replanning of the affected time range and report the result back to the missions in plan views. Checking the plan views, a mission may send operational service session refinement requests about one week before freeze. There may be several refinement cycles at this level (or none). As a last step, the missions send commitment requests for their service sessions. Sessions are frozen by the EPS, at a defined time before their scheduling.

The EPS is configured by the user requests as defined in the mission agreement (see section III.C.1) and by the capabilities of ESTRACK facilities as defined in the facility model (see section III.C.2). Creating and updating the EMP means for the EPS, to find for each request a service offered by ESTRACK or an external party. If all requests can be served, a plan has been created or updated successfully.

The interaction between the EMS Users (client missions) and EPS can be summarized as follows. • The network service requirements of the client missions are specified statically in mission agreements,

which comprise o User service definitions, which specify the required network operational services (telemetry

reception, telecommanding, ranging, etc.)

o Standing orders, which specify when and how services shall be provided in a generic manner • The client missions provide dynamic input during operations via event files, which include orbital event

predictions and specific mission events relevant to the network service allocation process • The network service allocation process updates periodically the ESTRACK Management Plan (EMP),

which identifies the network service sessions that are implemented by each ground stations • The client missions interact with EMS in order to

o Temporarily modify their network service requirements within limits given in the mission agreement

o Accept the service sessions proposed by EMS o Refine the service sessions proposed by EMS, providing the value of specific parameters to be used

for the generation of the facility schedules The example of interaction between a User and EMS at network service allocation level is illustrated in Figure 7.

EMS User EMS Event Files

Initial EMP View

Order Refinement

Updated EMP View

Service Session

Final EMP View

Service Session

Figure 7. Example of interaction with the EMS User

9

B. Network Service Allocation Examples The ESA mission model used for the network service

allocation is based on three main categories of missions. • The Deep Space missions (DS) • The Near-Earth missions (N-E), ranging from

Geostationary Transfer Orbit (GTO) to Lagrange type orbits

• The Low Earth Orbit (LEO) missions Commonalities exist between the network service

allocation requirements of the missions in one of these classes, due to the similar characteristics of the required services, of the operations to be supported, and of the general environmental conditions related to the type of orbit.

A number of generic network service allocation requirements have been identified, that will be formalized in the EMS mission model.

• One pass from AOS to LOS of a minimum duration per orbit (e.g. Envisat)

• Maximum continuous contact per orbit, with mandatory contact in a time period between two events specified for each orbit, and minimum hand-over duration (e.g. XMM, INTEGRAL)

• Maximum/Minimum total contact duration and number of passes within a period, with minimum pass duration (e.g. SMART-1)

• Maximum coverage for a constellation; in case of conflict between several S/C for the visibility of the same GS, the duration of the contact with the first S/C visible from the GS is maximized (e.g. CLUSTER)

• Etc. Those generic requirements are usually accompanied with a number of specific constraints. A more complete

example of network service allocation requirements is given in Figure 8. An example EMP is illustrated in Figure 9.

C. Relationship to SLE Service Management and other external providers management interfaces Support for cross-support and interoperability with other agencies and external network service providers is an

essential feature to be supported by EMS. At planning level, this means • providing an interface that can be used by non-

ESA client missions to request ESTRACK support;

• interfacing to external providers using their specific interface to request network services for ESA missions.

Non-ESA missions can obtain ESTRACK support from EPS after establishment of a mission agreement with the ESTRACK scheduling office. The corresponding mission model is stored in the EMS configuration database, and the external client mission can subsequently use the specific EPS interface for delivery of network service allocation plans and refinement of their standing orders or service sessions.

EPS interfaces to external service providers require the establishment of a model for the external provider facilities. This requires the facility model to cover the facilities managed by the external providers, and leaves to EPS the responsibility of requesting the external provider

1. Lunar occultation periods have to be avoided. 2. The minimum pass duration is 3-hour for Herschel, selected from

within the physical station visibility. 3. The minimum pass duration is 3-hour for Planck, selected from

within the physical station visibility. 4. The separation of passes should be 24 hours +/- 30 minutes. 5. The minimum pass elevation should be 10°. 6. Herschel and Planck passes should be scheduled within a period

of 8 hours. It is expected a ground station reconfigure time between spacecrafts of less than 30 minutes, including the pre-pass test.

7. The order Herschel-Planck or Planck-Herschel should be retained until a change is requested.

8. During some periods, due to the load on the NNO station it may be required to support one of the HP spacecrafts from Cebreros. The selection of the SC supported by Cebreros should be maintained for the full duration of the contention period.

Figure 8. Network Service Allocation Requirements for the Herschel-Planck mission

Figure 9. Example EMP

10

services when needed. As the interface to each external provider is specific to the provider, a proxy is used with each provider, which ensures the translation of the protocol of service assignment supported by EPS to the provider-specific protocol. For instance, the interface to the NASA Deep Space Network is implemented as a four-phases process, through which service requests are iteratively refined.

D. Relationship to SLE Service Management The standardization of the interface between users and providers of network services is currently being addressed

by the SLE Service Management Group of CCSDS. When this standardization is completed, EMS should be able to provide a standard interface to non-ESA missions and to use the standard interface for interaction with external providers. On the external provider side, this would result in the development of a proxy supporting the CCSDS standard protocol. On the mission side, the issue is slightly more complicated, as we explain below.

The EPS is primarily dedicated to the allocation of the network services of ESTRACK to ESA missions, and therefore integrates elements of the organization of the station network scheduling that are specific to ESA. The standardization currently proposed by the SLE Service Management Group assumes limited dynamic in the planning capability of the service providers, and does not address the actual network service allocation planning, which ESA missions expect to be done by EPS. It is therefore assumed that a CCSDS SLE Service Management standard interface will be provided for non-ESA missions only, and that the ESA missions will interface to standardized service providers through EMS.

The relationship between EMS and SLE Service Management elements is summarized in Table 2.

Table 2 Comparison of EMS and SLE SM elements EMS SLE Service Management Mission agreement Service session Configuration profiles Conf. profile parameters Service session refinement SLE service instances

Service agreement Service package Carrier profile Scenarios Service package “editing” SLE service instances

E. Implementing the ESTRACK Planning System In line with the software re-use policy of the

European Space Agency, the implementation of the EPS is based on reuse of software and design from the following sources.

• The Enhanced Kernel Library for Operational Planning Systems (EKLOPS) embedded in the Venus-Express and Mars-Express Mission Planning Systems, which was developed by VEGA for the European Space Agency. This set of libraries that support all aspects of the development of an operational planning system for space mission provides the core of the planning functionality required for the development of the EPS, and drives the general system architecture depicted in Figure 11.

• The ESOC Ground Operations Software (EGOS), which provides infrastructure components for generic functionality such as system processes location, system processes management, system processes monitoring and control, system static/dynamic configuration management, services Management Framework (SMF), Users and Privileges management, Events/Alarms management, Files management, and Generic File Transfer.

• The lessons learned from the prototyping of the EPS functionality carried out during the requirement capture phase.

Design Re-Use Code Re-Use

ESTRACK Planning System

EKLOPS-Based EMS

(EPS) Prototype

Languages for Mission

Planning study Results

EGOS

Components

EKLOPS-Based

MEX/VEX MPS

ESOC/VEGA/3rd Party Development

ESOC CFI ESOC/VEGA Development

Figure 10. Approach to Software Re-use

11

• The results of the Languages for Mission Planning study of ESOC, which proposed a language to formalize the representation of goals and constraints in mission planning systems, therefore providing the basis for the formalization of part of the EMS mission models.

The EPS is currently in development at ESOC, and will be delivered end of July 2006 for operational

acceptance.

V. Conclusion This paper introduced the ESTRACK Management & Scheduling System (EMS), a suite of applications that

support the new network management and scheduling operational concept of the European Space Agency, based on automation of the network service allocation and on generalized remote monitoring and coordination of the ESTRACK facilities at network level. It focuses on the planning component of EMS, the ESTRACK Planning System (EPS), which will ensure flexible allocation of network services to the client missions by relying on the formal representation of the client’s needs expressed as network service requirements.

This evolution will improve the usage of the ESTRACK resources, allow the Agency to face the growing need for network cross-support, and increase the load of ESTRACK in a controlled manner.

Master Operation

s

Plan Engine

Planning Input

Report Generator

Master Plan Plans Holding Area Master Area

Event Files

Standing Order Refinement Requests Operational Service Session Refinement Requests

Operational Service Session Commitment Requests Allocation Plan (external facility)

Event File Acceptance Report Plan Views Notification of mission changes to committed operational service sessions

Configuration Database

Figure 11. ESTRACK Planning System Architecture

12

References 1Concept for ESTRACK Management and Scheduling System (EMS), ESTK-MGT-TN-1001-TOS-ONF, Issue 1.0, May

2003 2ESTRACK Operations Manual, Volume 2, Network Control Procedures, TS-ESTR-OPS-OM-1001-TOS-ONF, Issue 7.0,

March 2000 3Station Commitment and Utilisation Tool, User Requirements Document, DTOS-GF-URD-1001-TOS-ONF, Issue 2,

Revision 2, August 2001 4Monitoring and Control Interface to Ground Station Controllers -Requirements, Analysis and Design, GSC-ICD, Issue 1,

Revision 0, December 2002 5Service Management – Service Request Operations Concept, CCSDS 910.14-W-1, White BOOK, April 2003 6Space Link Extension- Service Management, Xml Service Request Specification, CCSDS 910.15-W-1, White BOOK,

March 2003. 5M.Niézette and A.Pena, Planning the Usage of the ESTRACK Network, in Proceedings of the Fourth International

Workshop on Planning and Scheduling for Space (IWPSS'04), Darmstadt, Germany, June 2004. 6J.Noll and R.Steel, EKLOPS: An Adaptive Approach to a Mission Planning System , in Proceedings of the 2005 IEEE

Aerospace Conference, Big Sky, Montana, March 2005. 7Marc Niézette, Ian Shaw, Erik Noréus, Robin Steel, Jörg Noll, Simon Kellett, Helmut Schönhardt, Planning with EKLOPS:

Lessons Learned and Latest Developments, in Proceedings of the Sixth International Symposium on Reducing the Cost of Spacecraft Ground Systems and Operations (RCSGSO 2005), Darmstadt, Germany, June 2005.