Editor’s note: In July 2013, Alphasat, Europe’s largest and most sophisticated telecommunications satellite, was launched from Kourou, French Guiana. In addition to its main commercial payload, four ESA-sponsored Technology Demonstration Payloads (TDPs) are on board. These are provided by different research institutes, which are responsible for defining in-orbit demonstration tests of their new technologies. To optimize this flight opportunity, detailed coordination of the complex and possibly conflicting payload operations is required. This is one of the roles of the new TDP ESA Coordination Office (TECO). We spoke with Nicola Policella, lead designer of the TECO system and now the TECO Service Manager at ESOC (access the original news via ESA web).
Alphasat is a large telecommunications satellite primarily designed to expand Inmarsat’s existing global mobile telecommunication network. It was engineered and built by Astrium through a public–private partnership (PPP) between ESA and Inmarsat. It is the largest European telecom satellite ever built, exceeding 6.6 tonnes at launch. Its solar array, spanning almost 40 m, generates more than 12 kW of power. Credit: ESA
Q: What does the TECO system achieve?
To cope with the payload coordination requirement, an advanced planning and scheduling software system, the ‘TECO System’, was designed to support Alphasat operations and, in particular, to manage and coordinate the payload requests.
The system was developed on top of the Advanced Planning and Scheduling Initiative (APSI), a planning framework implemented in software, re-using some of its general modelling and solving functionality, and integrating ad-hoc evolutions to match the specific Alphasat TDP requirements.
The TECO system was designed to be completely automated, which means it can run without any human intervention for nominal operations, and fulfils the need to autonomously provide end users (i.e. the various TDP operation centres) with the necessary information to understand the planning process, the analysis of the input requests, and the final operation plans.
Alphasat Poster – Technology Demonstration Payloads
It is worth remarking that the TECO planning system was designed to cope with requirements like autonomous conflict resolution, which were new for ESOC. TECO functionality is ready to be incorporated into mainstream infrastructure planning and scheduling systems so it can support the operations of future missions.
Q: Can you describe the technology?
The system core is based on a planning engine, which has the task of allocating the various requests received from the payload owners by satisfying numerous constraints and maximizing the number of fulfilled requests.
The planning engine was developed based on advanced concepts coming from the area of artificial intelligence planning and scheduling. In particular, the engine was developed as a plug-in for ESA’s APSI framework (an ESA funded framework to developed advanced planning and scheduling solutions).
To give an idea of the size of the problem, in the past we had cases where there were more than 500 payload activity requests to be organised into a single plan covering one week of payload operations.
Q: What are the TECO results to date?
The first benefit relates to how we use advanced planning and scheduling approaches enable us to suggest and introduce a change in the originally intended planning cycle. In fact, the initial cycle did not foresee any iterations between TECO and the external TDP partners, being limited instead to a single exchange of planning product inputs and outputs. Due to the short solving time, the system is capable of providing timely feedback to the external partners in case of conflicts between requests, thus allowing them to resubmit their planning inputs in an iterative way.
Keeping an eye on TECO: Nicola Policella at ESOC Credit: ESA – CC BY-SA 3.0 IGO
Another benefit: modelling of the solution includes information about why a task may have not been allocated. In fact, there are many different reasons for why a task might not be allocated; for example, invalid input files, ill-defined task requests, tasks conflicting with spacecraft status, tasks conflicting with other task requests or tasks not allocated because they are linked to conflicting tasks. It is worth remarking that a proper explanation is fundamental to achieve effective iterations among the different actors involved (i.e. TECO and the payload owners).
A fundamental design decision, in our experience, was to have a flexible system architecture, which allowed us to cope with several changes introduced during the definition of the problem as well as during the actual operational phase. This aspect was crucial to coping with the evolution of the requirements during the various phases of the project.
Contact
N. Policella
ESA/ESOC, Darmstadt
Tel +49 6150 90 2258
Discussion: no comments