CNES Mission Operations System Roadmap: Towards Rationalisation and Efficiency with ISIS

Abstract

In the middle of the two thousand, CNES was operating around 15 space vehicles, using five different mission operations systems. The rationale was that each spacecraft type or product line had its own mission operations system, so as to have an optimised system for each kind of vehicle. This was leading to ‘local’ optima. This paper aims at showing how CNES has chosen to improve its global efficiency for mission operations system development and for spacecraft operations. In order to find a better development and operations cost optimisation, as well as an optimisation of the organisation of its space operations, CNES studied by about 2006 the development of a new mission operations system that must be usable for all the future missions operated at CNES. The decision to achieve this development was taken in 2010. This new system is developed in the frame of the CNES ISIS project (Initiative for Space Innovative Standard). The ISIS project aims at optimising the CNES space systems development by standardising for CNES missions the platforms together with the mission operations system. The payload and the payload operations and data system are out of the scope of the ISIS project as they are specific to each mission. ISIS only deals with the interfaces towards the payload world. The whole ISIS project is achieved in partnership with two spacecraft manufacturers: TAS (Thales Alenia Space) and ADS (Airbus Defence and Space). The new mission operations ground system is called LP CCC ISIS (French acronym for ISIS command control centre product line). The paper explains how the ISIS project was born at CNES, the rationale of the project, the area and mission types it covers and the objectives it follows in order to perfectly understand the context in which the LP CCC ISIS is being developed. The ISIS project description also gives the rationale for optimising the space systems development and unifying the operations concept at CNES. This project is designed as the follow-on of the successful CNES/TAS (Thales Alenia Space) mini-satellites product line called PROTEUS. The main PROTEUS concepts are recycled in ISIS and are completed with all the CNES, TAS and ADS past experience in various space systems development and operations. The paper shows the major role given to various CCSDS and ECSS standards in this process. The context being explained, the paper addresses then the objectives of the LP CCC ISIS (for instance better performances to anticipate the evolution of the space systems, more automation to reduce operations costs and securing at defence missions level). It also addresses the various foreseen uses of the LP CCC ISIS which are not limited to mission operations system but also cover, for instance, test bench for instrument and satellites AIT (assembly, integration and tests) or remote analysis toolbox for on-call operators. This is due to the will to optimise software developments in all fields connected with satellites monitoring and control. Thereafter are described the main concepts on which the LP CCC ISIS relies and how they help fulfil the various objectives assigned to this new product. The main topic here is about service-oriented architecture (SOA), CCSDS Mission Operation standard and splitting of the software into components. This is completed with a high-level technical description of the LP CCC ISIS, showing all the functions covered by the software, how they are organised and what is to be done when the LP CCC ISIS is to be adapted to a new mission. The industrial organisation for development and integration/qualification phases will be described. This will highlight the expected benefits from this new product line. For instance, it will be shown how different systems for different uses can be built from the LP CCC ISIS components or the advantages of using the LP CCC ISIS software in various contexts and not only in mission operations system. The paper will give an overview of the development planning and of client missions at CNES for the LP CCC ISIS. A first evaluation of the benefits those missions have seen by using the ISIS standard and the LP CCC ISIS will be exposed, considering that CNES is only in assembly and tests phase as the first launch has not yet been achieved. The paper touches on the links with the European Ground System Common Core (EGS-CC) initiative. EGS-CC fulfils similar objectives and thus exchanges have taken place between the two initiatives. CNES is a member from the beginning of the EGS-CC steering board and of the EGS-CC system engineering team.

1 Introduction

In the middle of the 2000s, CNES was operating around 15 space vehicles, using 5 different mission operations system. The rationale was that each spacecraft type or product line had its own mission operations system, so as to have an optimised system for each kind of vehicle. This was leading to ‘local’ optima. This paper aims at showing how CNES has chosen to improve its global efficiency for mission operations system development and for spacecraft operations.

In order to find a better development and operations cost optimisation, as well as an optimisation of the organisation of its space operations, CNES studied by about 2006 the development of a new mission operations system that must be usable for all the future missions operated at CNES. The decision to achieve this development was taken in 2010.

This new system is developed in the frame of the CNES ISIS project (Initiative for Space Innovative Standard). The ISIS project aims at optimising the CNES space systems development by standardising for CNES missions the platforms together with the mission operations system. ISIS project is conducted by CNES in partnership with two major satellite manufacturers, TAS and ADS. All ISIS documents are discussed and signed together by the three partners.

The paper presents the ISIS project and the new CNES mission operations system. It then briefly explains the links between ISIS and EGS-CC before giving a word of conclusion.

2 The ISIS Project at CNES

2.1 ISIS Rationale and Scope

ISIS began as a study of a follow-on of the CNES PROTEUS low-cost satellite family.

PROTEUS system was developed during the 1990s. Six satellites have been built, three of them still being in flight. This system was made of:

• A platform and its interfaces, designed for multipurpose usage.

• A command/control ground segment and its interfaces, compliant with the platform, including small TM/TC stations.

All that is related with the payload is out of the PROTEUS scope. Only the interfaces with the payload or the payload processing centre for instance are part of the PROTEUS perimeter. Each mission had to design its payload and payload programming and processing centres so as to be compliant with the PROTEUS resources and interfaces.

The platform/command control ground segment package was reused as is or with only slight modifications for each mission. Having designed a reusable system was a major contributor to the low-cost objectives of PROTEUS for the missions.

Cost reduction is one of the main ISIS objectives, and the idea is to recycle PROTEUS main concepts as they have proven to be successful. But in the frame of ISIS, it has not been designed a new platform like PROTEUS did, but it has been decided to write a CNES internal standard (this explains the ISIS acronym: Initiative for Space Innovative Standard). This standard contains specifications both for platform and command control ground segment. This standard applies to all future CNES missions. This standard is both:

• A whole set of specifications that a mission can reuse to write its own system specification, platform specification, board to ground interfaces, command control ground segment specifications and ground interfaces. Each mission slightly adapts the specifications to its needs.

• And a set of specifications from which ISIS products can be developed and reused from one mission to another.

Applying the standard to all CNES mission is the way cost savings can be done, by reusing products compliant to the standard from one mission to another. Applying the standard also leads to have a single operation concept, thus allowing more easily the operation teams to switch from one mission to another.

The ISIS scope is the same as the PROTEUS one, that is to say platform, command control ground segment and interfaces with the payload world. The only difference is for the stations, as ISIS uses the existing CNES multi-missions stations network instead of developing dedicated stations.

ISIS technical area of concern is basically made of all the means and services recurrently involved in a space mission, for both operations, and satellite development. It is commonly agreed that those services do not make significant difference and are not subject to competition between major space companies any longer. This situation makes possible to define standards facilitating reuse and rationalisation.

The main components this standardisation can focus on are:

• The platform services for the payload: mechanical/thermal/propulsion, electrical and power, data handling, payload data management, dynamics and AOCS, software and operations.

• The control ground segment (CGS) which may be multi-missions.

• The external interfaces: satellite-launcher interface, platform-payload interface and interface between the control ground segment and the mission ground segment.

• AIV, test beds and simulators, system database.

On Fig. 1, the elements in the ISIS scope are in green, the payload world elements are in purple and the reused stations network is in blue.

Fig. 1

ISIS project scope

2.2 ISIS Covered Missions

ISIS has been designed to cover a wide variety of missions. Only telecommunication missions and interplanetary missions are out of the ISIS scope. Many other kind of missions can be covered for instance LEO, MEO and HEO.

After studying all those type of missions and having defined a segmentation for each technical part of the system, ISIS is currently developing LEO missions’ aspects as the first ISIS missions are all LEO missions.

If another kind of mission is to be taken into account in the future, additional studies will be made to achieve the segments eventually not yet developed.

So the whole ISIS segments will be developed little by little according to the missions’ opportunities.

2.3 ISIS Optimisation Processes

The rationale for optimising the space system development process as well as the operations with ISIS is to apply a precisely defined standard to all CNES missions thus allowing:

• Application of standard and homogeneous process for successive space systems development.

• Reuse of products.

• Reuse of validation statuses on products thus optimising the tests to be conducted.

• Application of a standard operation organisation allowing to interchange easily operators between missions.

• Reuse of operational procedures limiting the workload to prepare successive mission operations.

This can be summarised as limiting the workload by maximising the reuse of specifications, products, processes and validation statuses from one mission to another on all recurrent fields.

2.4 ISIS High-Level Objectives

ISIS standards aim at helping space mission providers to propose highly performing systems as well as secured and cost-effective development and operation processes.

2.4.1 Cost Reduction

It is a strong requirement that the ISIS approach leads to significant costs reduction from mission point of view. The main drivers for costs reduction are:

• Development efficiency: the right inputs at the right time, the right tool for the right study.

• Operation efficiency, to limit the manpower required during tests and operations.

• Simplicity and robustness, to limit the knowledge required to operate the system (test or flight procedures development for example), and the flight domain to be validated.

• Wide reuse of system components without modification, which implies wide and well-adapted flight domain, versatility, but also documentation to help missions use them in the best way.

Cost reduction shall be considered from a point of view common to all missions: an option can be not optimal for a given mission but must be optimal for the missions all together.

Cost reduction shall also be considered from a point of view common to all mission phases: a service may be expensive during development, but cost efficient during operation.

The cost of standardisation shall be taken into account in the economic rationale, considering that, at short term, ISIS can apply to a limited number of decided missions.

2.4.2 Secure Developments

In early phases of mission development, it is useful to know the typical performances, development plans and costs of product lines and associated processes of previously flight-proven solutions, in order to ease the system architecture definition process and to set up a well-defined and reliable development plan.

Consolidation of such flight-proven reusable product lines as well as inputs defining how to use them is a major way to secure developments and is the basis of ISIS approach.

2.4.3 Support Innovation

Innovation is not the main goal of ISIS approach. However, standards and technology evolution as well as obsolescence imply permanent changes, and it is often difficult, for costs and risks reasons, for an isolated mission to embed innovation.

ISIS brings out solutions to help innovation be taken into account and to rationalise the way it is performed.

2.4.4 Improved Flexibility and Flight Domain

Flexibility and flight domain improvement are a way to enlarge the domain where generic product lines can be used and at the end a plus for efficiency.

Flexibility must be understood as the ability of product lines (on-board or ground), of adapting locally to particular needs, without changing the whole product line outline.

Flight domain improvement must be understood as the ability of part of product lines to be used in wider mission conditions (LEO/GEO, radiation level for example). This implies enlarging the capacity of single solutions, or breaking down the performance ranges into optimised segments.

ISIS shall support flexibility and flight domain improvement.

2.4.5 Compatibility with International Standards and Regulations

As the French National Space Agency, it is the CNES duty to promote International and European standards and regulations, especially when CNES was involved in their definition. At the same time, such compatibility guarantees better reusability, which is an important source of cost reduction. Regulations that restrict exportation must also be taken into account.

The following guidelines were given to ISIS:

• ISIS-based products shall be based on state-of-the-art technologies.

• ISIS-based products shall comply with international, European and state-of-the-art standards (CCSDS, ECSS…).

• ISIS shall consider and make the most of other European standardisation initiatives.

• ISIS-based products shall comply with classical space regulations: ITU, law on space debris and French LOS.

• Components under ITAR, EAR and other regulations limiting products exportation shall be exhaustively identified and shall not be used in key building blocks.

• French export regulation constraints shall be identified and taken into account to avoid restrictions on ISIS products exportation.

• ISIS safety rules shall be compliant with the major launch sites requirements.

First, it guarantees that the solutions developed by ISIS partners will be compatible with other customers’ needs. Second, it guarantees that developments required by or for other customers will be close to ISIS standard, and contribute to ISIS partners’ effort to convergence.

Until now, ISIS has produced 60 documents that can be reused by the different missions. Among them, 30 are ECSS documents that have been tailored.

2.4.6 Support European Industry Product Lines

It is another CNES duty to support the European industry. ISIS must contribute to this goal by establishing partnerships with the prime contractors in order to support product lines and platform equipment improvement and competitiveness. ISIS benefits must be profitable for other customers than CNES.

2.4.7 Missions

ISIS standard shall be compatible with the following classes of missions:

• French institutional: defence, multi-lateral science or institutional cooperation.

• European space agency missions (except interplanetary).

• Export.

2.5 Position of the LP CCC ISIS in the ISIS Project

At the same time ISIS was being defined, CNES was thinking about developing a new command control centre software product line that would be used by all the future CNES missions. The aim was to have a single software for the future command control centres in order to optimise the missions’ costs for the command control ground segment.

When the ISIS standard has emerged, it became obvious that this new product line had to be compliant with the ISIS standard. The ISIS standard applied to all future CNES missions was the ideal frame to allow using a single product line for operations. This is how the new CNES command control centre software product line has been designed as the LP CCC ISIS.

So the LP CCC ISIS is an ISIS standard compliant software product line reusable for any ISIS compliant mission command control centre. It is developed in the frame of the ISIS CNES project.

2.6 ISIS Operational Concept

The ISIS mission command chain and the ISIS mission data chain are based on the following concepts.

2.6.1 Mission Command Chain

Mission operators from the mission centres are responsible for payload operations whereas operators from the control centre are responsible for platform operations, as well as maintaining the satellite and the control ground segment in operational conditions.

Operations commanded by mission operators from the mission centres are called mission operations.

Operations performed by satellite operators from the control centre are called satellite operations. They include maintenance operations on the payload.

The mission command chain is based on the following concept (Fig. 2).

Fig. 2

Mission command chain

Mission planning is performed by mission operators. For some missions, payload activities can be planned independently from platform operations (power resources are large enough, the payload includes its own data storage and transmission means, no specific attitude profiles are needed). In this case, mission operators provide the control centre with payload commands only.

If the payload activation is conditioned by platform resource level (power for example), these limitations have to be taken into account in the mission planning process.

When payload activities are coupled with platform activities (e.g. specific attitude profiles are needed), mission operation files include requests to the control centre to perform platform operations. Requests are high-level commands and are translated into telecommands by the control centre.

The control centre plans the satellite contacts with the ground stations and processes the operation files to generate telecommand plans. Then, these TC plans can be sent to the destination satellite next time it is in contact with a ground station.

If the mission has no specific needs and there is no coupling with payload operations, standard attitude and downlink management operations can be performed by the control centre in an automated way.

In any case, the control centre and the platform are responsible for the satellite safety. Ground and on-board mechanisms guaranty that requests coming from the mission will never put the satellite at risk, or (as far as possible) in safe mode. Depending on mission characteristics and the nature of the erroneous programming, the result may vary from operation files reject to mission interruption.

The presence of control operators is not necessary to process a mission operation file. The process is automated, and mission operators receive a failure report in case of problem and all the information necessary to follow the plan acceptance and execution by the satellite through satellite telemetry. In case of problem, real-time reaction from the control centre alone is not possible.

2.6.2 Mission Data Chain

The data distribution chain is based on the following concept (Fig. 3).

Fig. 3

Data distribution chain

Several options are possible:

• All or part of payload data are recorded and transmitted to the ground through the same means as platform data (platform memory and S-band stations).

• Mission data are recorded and transmitted through a multi-missions X-band data service managed by control operators.

• Mission data are recorded and transmitted by mission-specific equipment considered as payload instrument and dedicated ground stations managed by mission operators.

Mission data management is performed by mission operators. Downlink operations are planned in the mission plan consistently with payload operations.

Raw (and ciphered if necessary) mission data are retrieved by the mission centres. Mission-specific data processing is performed before delivering the products to end users. Mission data should include all platform ancillary data which are necessary to mission data processing.

3 The LP CCC ISIS

3.1 Objectives

The main objectives of the LP CCC ISIS are:

• An upgradeable architecture to be adaptable to various missions with limited costs, even for non-ISIS missions.

• The capacity to have modifications to fix bugs or to insert adaptations with limited amount of source code to modify and to deliver.

• A distributed architecture and a scalability of the software so as to take into account various hardware deployment and so as to have a capacity to upgrade the hardware and to adapt the deployment, for example, when adding a satellite in a multi-missions centre.

• Better performances to anticipate the evolution of the space systems.

• More automation to reduce operation costs.

• Securing at defence missions level.

• Taking the best of CNES operation concepts in the past 20–30 years.

All those items participate in the step beyond CNES wants to do in its satellite operations.

3.2 Various Possible Deployments

The new ground system product line shall be used for:

• Civilian and military mission control systems including nanosatellites and constellations (those last two points being at this time only under study).

• Main control room/spacecraft experts room.

• Standalone flight dynamics workstations.

• Expert workstations (offline telemetry processing and analysis).

• On-Call operator laptop (access to MCS data for first level diagnosis).

• Simulator test bench procedures execution and telemetry monitoring.

• AIT/On-board equipment test bench (Preparation and execution of spacecraft tests or instrument tests).

This will to design the software thinking about various utilisation contexts from the beginning of the development reflects the will to optimise all software development in the field of satellite command control and testing, but also to have homogeneous practices and tools for all the different jobs like designers, operators, experts and AIT teams.

3.3 Main Concepts

The key features of the ground system product line are:

• To be able to build a multi-missions, multi-satellites control centre: the TC sending process is devoted to one satellite, TM visualisation is able to process, monitor and display several satellite flows. This capacity allows to have a single hardware infrastructure for several satellites belonging to different mission, or for a multi-satellites mission.

• To be able to have several independent working sessions in parallel for a mission, so as to gather in the same control centre both the operational activities and the tests activities (new procedure validation for instance, or new software release validation before using it on the operational line).

• To be able to easily cope with new missions: the product line is organised as a set of generic software components that address common requirements. Additional components can be added to address mission-specific requirements.

• To rely on a service-oriented architecture which enables easy software adaptability. The service-oriented architecture is based on the CCSDS Mission Operations standard.

• To be compliant with security constraints imposed by defence missions. The architecture and the technologies used for the ISIS baseline shall meet the security requirements of a defence mission.

• To provide software components reusable outside of the product line. For example, TM parameters processing, TM visualisation, PUS services… can be reused for payload control centres, for on-board equipment validation, etc….

• To have a full automation of the control centre: every function can be activated by the automation subsystem, either directly or through a procedure.

• To have the same language used for FCP, OBCP and ground automation procedures.

• To have operational data divided in two categories: time-based data (non-relational time-stamped data like telemetry, command logs, events…) and documents (complex version-controlled files like procedures, mimics, memory images, reports…). Time-based data is immediately available.

All those features intend to get a maximum of flexibility in all the phases of a mission (design, development, validation and operations).

3.4 High-Level Technical Description

The new ISIS ground system product line provides the whole control centre functions. This chapter gives a description of the functions, of the architecture and of the performances. It begins giving an overview of which standards are used for the LP CCC ISIS.

3.4.1 CCSDS and ECSS Standards in the LP CCC ISIS

3.4.1.1 CCSDS Standards

The Consultative Committee for Space Data Systems (CCSDS) was formed in 1982 by the major space agencies of the world to provide a forum for discussion of common problems in the development and operation of space data systems. Since its establishment, it has been actively developing recommendations for data- and information-systems standards to promote interoperability and cross support among cooperating space agencies, to enable multi-agency spaceflight collaboration (both planned and contingency) and new capabilities for future missions. Additionally, CCSDS standardisation reduces the cost burden of spaceflight missions by allowing cost sharing between agencies and cost-effective commercialisation.

The LP CCC ISIS relies on Consultative Committee for Space Data Systems (CCSDS) standards for:

• Space link: CCSDS TM and TC space data link protocols.

• MCS/ground station communications: CCSDS Space Link Extension Services.

• MCS software architecture: CCSDS Mission Operation services and XTCE.

The product line design relies on the CCSDS Mission Operations standard (MO) which follows the principle of service-oriented architecture (SOA) and defines a set of end-to-end services and common object model to describe the data. The standard also defines a MAL (message abstraction layer) to provide independence from the message encoding and transport technologies.

3.4.1.2 ECSS Standards

ECSS is a cooperative effort of the European Space Agency, national space agencies and European industry associations for the purpose of developing and maintaining common standards. Requirements in this standard are defined in terms of what shall be accomplished, rather than in terms of how to organise and perform the necessary work. This allows existing organisational structures and methods to be applied where they are effective, and for the structures and methods to evolve as necessary without rewriting the standards.

Most of the ECSS documents of the engineering branch have been tailored in ISIS. The product line relies on ECSS standards for:

• ECSS-E-70-31 Mission Database Layout, used to define the conceptual data model of the system database.

• ECCS-70-01 Spacecraft on-board control procedures language definition, used to derive two specification documents: the specification of OBCP user-needs and the specification of the procedure edition and validation user-needs.

• ECSS-70-32 procedure language definition, used to specify the procedure language for satellite and ground operations.

• ECCS-70-41 PUS A board-to-ground interface. ISIS provides CNES missions with a tailored PUS specification that simplifies the use of PUS services and complies with current implementations of PUS. Each mission can then select PUS services and subtypes according to its needs.

3.4.2 LP CCC ISIS Functions

The functional analysis of the ISIS ground system product line functions has identified the following high-level functional sub-systems:

• Monitoring and control.

• Data management.

• Visualisation.

• Automation.

• Flight dynamics.

• Mission operation support.

• Infrastructure.

• Monitoring and control

Monitoring and control functional subsystem is composed of functions necessary to communicate with ground stations according to CCSDS SLE standard, functions to receive and process telemetry, functions to generate and send commands, encrypted or not, and functions to manage ECSS PUS services.

• Data management

Data management functional subsystem (also named DataStore) contains functions related to data archive, management and retrieval. All the data received and produced in the control centre are handled in the DataStore which is the exclusive storage place inside the control centre: stored data are for instance telemetry packets and parameters, sent commands, events and operational products (procedures, mimics, sequence of operations…). This subsystem also manages the system database made from the satellite database delivered by the satellite manufacturer completed by various data such as derived parameters, monitoring rules and system parameters.

• Visualisation

Visualisation functional subsystem consists in a graphical user interface for satellite mission monitoring. It allows creating graphical elements like mimics, curves, tables and history views, to display time-stamped data stored in the DataStore on these graphical elements, and to apply local monitoring. Various kinds of data can be visualised together on a single view to allow cross analyses. This subsystem can be used both during real-time operation and during offline operations like telemetry replay.

• Automation

Automation functional subsystem gathers all functions related to control centre operations automation: procedures and sequence of operations preparation and execution. The sequence of operations preparation relies on an automatic computation of the activities based on predefined rules adapted to each mission.

• Flight Dynamics

Flight dynamics functional subsystem is responsible for all processing dealing with attitude and orbit management.

• Mission operation support

Mission operation support functional subsystem gathers functions related to events management and configuration, on-board software and images management, reports creation and report templates management, operational tasks and notes management.

• Infrastructure

Infrastructure functional subsystem is comprised of functions related to the low-level layers of the control centre, typically dealing with user authentication and access rights management, internal communication management, system’s configuration, exchanging files with external entities, printing and managing hardware.

3.4.3 LP CCC ISIS Architecture

3.4.3.1 Layers and Components

In the LP CCC ISIS architecture, all subsystems are divided into several components (in average around ten components per subsystem). All those components are stateless and give services. The components call services of other components according to their needs and all interactions are done in an asynchronous way. This allows that components can easily be replaced by another implementation if necessary, for instance to take into account a mission specificity. This allows also that only the components concerned by an adaptation are modified and the others remain identical. Only the modified components are delivered in a new release instead of the whole subsystem in monolithic architectures.

In addition, the LP CCC ISIS architecture is a layered architecture in which all the applications are in the upper layer (the application layer) and the infrastructure is in the lower layer. It is in this lower layer that the communication component (libcom) and the directory service that contains all information to access the various services can be found. This is illustrated in Figs. 4 and 5.

Fig. 4

ISIS product line layers overview

Fig. 5

Layered architecture

The libcom allows components to exchange messages to interact. For instance, there are messages for activating a service, messages for telemetry diffusion etc.… The directory service allows to know which services are available and where they can be called.

The libcom relies on the ZeroMQ technology and the directory service on the Redis technology. Both are compliant with the CCSDS Mission Operations standard. The libcom implements the MAL part of the standard and the directory service implements part of the common services of the standard.

The MAL allows to have standard interaction patterns independent from the transport technology. If necessary, the transport technology can be changed without impacting the application layer.

Inside the application layer, we distinguish different types of components (see Fig. 6):

Fig. 6

Detail of the application layer

• The daemons that are permanently active.

• The processings that are launched on demand and that are stopped when their work is finished.

• The GUIs that are dedicated to the man–machine interface.

For instance, DataStore components that must always be available for storage are daemons, but the station connection component which is needed only during a satellite pass over a station is a processing launched just before the pass and stopped after.

Besides the components, the application layer can also contain scripts in Python. Scripts can be used instead of components when something light is to be done. In particular, scripts can be written by users if they need to add simple processing without asking an industrial development of a component or if they need to add quickly a first level of processing waiting for a later implementation as a component.

Last important elements are the configuration files of the components. They allow to tune the behaviour of the software.

Concerning the activation of the processing chains, nothing is hard coded in the components. Every task in the control centre has to be activated from procedures that are to be written in Python. So all the operational concept is implemented through procedures and can be tuned by the operators as they are responsible for writing the procedures. Those procedures are called GCP.

This is possible because all services given by the components are exposed trough APIs. Scripts can also use those exposed APIs and this is why scripts may replace components in some occasions.

Concerning the deployment of the software, the LP CCC ISIS is a virtualised, distributed application. The LP CCC ISIS is deployed on a topology of VMs on which the components are distributed. The contractor delivers a standard topology but it can be adapted by the customer when installing the software according to the mission needs.

For the subsystem development and validation, the contractor uses VirtualBox to create and manage VMs. For the operational deployment, CNES uses VMWare to create and manage VMs.

Distributing the application on VMs allows to do logical groups of components so as to avoid any resources conflict between components. It also allows to tune the resources of each VM according to the needs of each components logical groups. Distributing the software on VMs is the guaranty of an easy scalability of the application. For example, storage components can be duplicated to allow workload dispatching.

Virtualisation is used to be able to deploy on various hardware and various operating systems. For instance, it will be used to deploy the software on the experts’ laptop under Windows. Virtualisation will allow in the future to better manage obsolescence and to avoid software porting to follow OS evolution.

3.4.3.2 Main Internal Interfaces

Figure 7 shows the leading role of the storage subsystem. Each subsystem relies on the DataStore to store or retrieve all useful data:

Fig. 7

Main internal interfaces

• Telemetry and sent commands for monitoring and control.

• Procedures, sequence of operations and operational rules for automation.

• Visualisations elements for the corresponding component.

• Data context for flight dynamics.

• Configuration data and execution context for infrastructure.

• Reports templates, memory images or event and alert configuration for mission operations support.

Besides, each component can generate an event to report a particular behaviour to the user. At last, the satellite database definition is distributed to all components needing to manage telemetry and telecommands structure.

3.4.3.3 Main External Interfaces

Main external interfaces are shown in Fig. 8. Four external entities are identified:

Fig. 8

Main external interfaces

• The payload control centre which receives from the control centre all the data necessary to manage the mission: flybys data, telemetry, satellite configuration, orbit and attitude data. In response, the payload control centre provides the mission operations file defining the mission commands to send to the satellite.

• The ground stations network which is responsible for establishing the link with the satellite (telemetry and commands exchanges) and which provides data associated to ground stations and to external environment (for instance, solar activity).

• The satellite simulator whose main interfaces are telemetry sending and commands receipt.

• At last, satellite manufacturer who receives telemetry from the command centre for monitoring purpose, who supplies data related to the spacecraft, mainly satellite database and on-board software.

3.4.3.4 Flight Dynamics Subsystem Architecture

The FDS is made of a framework in which flight dynamics algorithms are integrated. The framework is in charge on one side of the integration and of the management of the interfaces for the flight dynamics algorithms and on the other side of the management of the interface with the LP CCC ISIS other components. The special feature for this subsystem is that the framework is developed as an ISIS component, while the flight dynamics algorithms are developed in the frame of another project at CNES called SIRIUS. SIRIUS aims at modernising all the CNES flight dynamics software. The FDS assembly is thus made from the ISIS FDS framework component called FDS toolkit and from various flight dynamics algorithms that are integrated with the FDS toolkit. The resulting FDS is dedicated to a mission. The list of flight dynamics algorithms is mission specific. The cost optimisation is obtained here through the reuse as is of the FDS toolkit from one mission to another and by the fact that most of the algorithms are reused from one mission to another. The mission tuning is done mainly through the algorithms.

Figure 9 shows the various items of the FDS, together with the infrastructure layer of the LP CCC ISIS.

Fig. 9

FDS architecture

Fig. 10

ISIS data flows

3.4.4 ISIS Data Flow Architecture and ISIS PUS Services

Data flows cover both telemetry/telecommands (TM/TC) and remote monitoring/remote commands (RM/RC). TM/TC connections with the stations are compliant with the CCSDS space link extension standard (SLE). SLE can be replaced by other connection protocols. For instance, a simple TCP/IP connection is foreseen for AIT needs (Fig. 10).

RM/RC are dedicated to the remote control of the stations. This possibility comes at CNES in addition to the standard remote control of the stations already done by the network operations centre. It allows doing some automatic checks on the station through the RM during the sending of a TC procedure for instance. It also allows to act on the station through the RC inside a TC procedure if necessary, which would not be possible if an interaction with the network centre was mandatory. RM and RC are only available when the station is booked for the mission. RM and RC are defined in the system database, so as to be decommuted or encoded through the same mechanisms as those used for TM/TC. When they are distributed inside the LP CCC ISIS system, those TM/TC and RM/RC data are translated into standard CCSDS MO data, transiting on the MAL architectured data bus.

Concerning the PUS implementation, some services have been customised for the ISIS standard (see Fig. 11 standard ISIS PUS services) but for every mission it is possible to add all the specific services needed (for AOCS TC for example).

Fig. 11

Standard ISIS PUS services

3.4.5 LP CCC ISIS Performances

The performance requirements of the product line have been defined according to the mission needs taking into account feedback from the missions operated at CNES and from new mission needs. They cover user access, real-time and differed telemetry and other generic requirements.

The main requirements deal with:

• Multi-satellite capabilities.

• Capacity of a single control centre hardware instance to allow routine operations on up to six satellites belonging to one or several missions.

• Growth potential: the control centre architecture shall allow operations on six satellites but it shall also have a growth potential to be able to be used for monitoring and control of constellation of around 50 satellites, with an adapted data storage capacity, but otherwise same performance level.

Generic requirements:

• The system shall be able to support up to 50 users in parallel, while meeting the specified performance requirements.

• The system shall support the possibility to start and manage at least 30 user-dedicated applications from within one client.

• It shall be possible to display at least 1000 telemetry parameters on 30 different operational places in real time (main control room/spacecraft experts room).

• The long-term trend analysis of 50 parameters over 1 year shall take no more than 10 min.

TM monitoring and archiving performances:

• 50 MB of raw platform recorded telemetry shall be available for beginning of archiving, less than 10 min after the LOS 0° of a pass.

• Monitoring and archiving of 50 MB of raw platform recorded telemetry shall be done in less than 5 min.

Telemetry parallel connections:

• The system shall be able to receive and archive all real-time telemetry data received from up to ten parallel connections (e.g. SLE service instances), at an overall rate of at least 20 Mbits/s.

Processing and archiving per second:

• The system shall be able to process and archive at least 100,000 monitoring parameter samples per second.

Telecommand data transmission:

• The system shall be able to transmit telecommand data at a rate of 64 Kbps, target performance shall be 512 Kbps.

Procedure sending performances:

• The time necessary for generating (sending) a procedure containing 20 telecommands, once all the necessary entries have been given by the operator shall be less than 4 s.

3.4.6 Technologies and COTS

In order to reach all the CNES requirements (in terms of performance, genericity, modularity, maintainability and easiness of deployment), an innovative technical solution has been thought, breaking with legacy system solutions. Some of the key choices are:

• CCSDS MO that covers communication, archiving and M&C. ISIS needs automation, visualisation, flight dynamics, on-board software management, reporting, deployment, file transfer, supervision… ISIS own services based on the MO framework have been created.

• A lightweight communication library: ZeroMQ.

• Simple efficient storage for time series: Google LevelDB.

• Python as the common scripting language: FCPs and GCPs will be written in Python. Native Python access to all the ISIS services (C++ mostly) is provided.

• GUIs rely on Qt and JavaScript.

3.4.7 LP CCC ISIS Adaptation to a Mission

The LP CCC ISIS is made of a reusable set of components that have been developed from the ISIS standard set of specifications and from the past experience of CNES in command control centre developments. In order to cope with mission specific needs, several possibilities exist:

• In the development phase:

  • First, if possible, the reusable ISIS components are enhanced with mission-specific needs, provided that the component remains compatible with all other ISIS missions. For instance, ISIS does not use CCSDS segmentation for TCs but one of the ISIS missions needs this segmentation. So, it has been added to the encoding chain capacity as a configurable option that a mission can use or not.

  • Secondly, if the mission-specific need is not covered by an ISIS component, a mission-specific component is developed in compliance with the technologies and the architectural principles of the LP CCC ISIS and is designed to be run and to interact with the ISIS components. If the mission-specific function is already covered by an ISIS component that is not compliant with the precise mission need, the mission-specific component replaces for the mission, the existing ISIS component, and it is deployed in place of the ISIS component in the mission control centre. If the mission-specific function does not exist in the set of reusable ISIS components, the mission-specific component is deployed together with all the ISIS reusable components in the mission control centre.

• During the assembly, integration and validation of the mission control centre:

  • The ISIS configuration files must be tuned with the mission-specific data and configuration values. In particular, each mission comes with its own satellite database.

  • In addition, scripts and procedures can also be used to fulfil certain mission-specific needs.

Figure 12 shows that inside a mission centre, we can have ISIS reused items (in grey) and specific mission items that can be added if necessary (in blue). The whole infrastructure is common to all missions. Only application layer can include mission-specific items.

Fig. 12

Addition of mission-specific items

The flight dynamics system is adapted slightly differently to a mission because it is built by assembling a generic ISIS framework together with flight dynamics algorithms that are developed out of the ISIS development. The adaptation to a mission is done on the algorithm part but the generic ISIS framework is reused as is for all missions. This framework interfaces on one side with the flight dynamics algorithms and on the other side with all the components of the LP CCC ISIS. Of course, if the flight dynamics algorithms of a mission need it, additional features can be added to the ISIS framework so as to remain compatible with all other missions and thus remaining generic.

The flight dynamics algorithms are designed so as to be adapted similarly as ISIS components are adapted to a mission:

• Either the algorithm is enhanced with new capabilities with ascending compatibility for all missions.

• Or a new algorithm is developed and deployed for the mission that needs it.

The ISIS generic framework for the FDS is called FDS toolkit.

3.5 Global Operational Scenario Inside the LP CCC ISIS

The typical routine activity inside an ISIS command control centre can be synthetically described as follows:

• Every week the sequence of operations is automatically computed from mission-specific rules. As a result, the next three or four weeks’ program is established and can be made operational after validation and eventual manual upgrades.

• Once operational, this sequence of operations is automatically executed by a scheduler. All operations are launched according to their beginning date and to the status of the previous activities. All this sequence of operations can be monitored through a GUI showing the operations with colours according to their status.

• Typical operations automatically started through the sequence of operation are:

  • The processing of the mission programming file that is sent at a frequency decided for each mission by the mission centre. It is processed to prepare the procedure to be uploaded to the satellite for payload programming.

  • The flight dynamics computation that take place automatically daily. This allows to monitor the orbit and prepare a manoeuvre if needed, to monitor the attitude, to program the attitude if needed. As a result, data files are produced and distributed inside the command control centre and towards external centres like the mission centre for instance. In addition, parameters for AOCS telecommands are computed and are sent in the control centre to components in charge of computing the telecommands and preparing the TC files to be uploaded.

  • Daily FCPs preparation to be sent on-board during the satellite passes of the day. Only FCPs validated on a satellite simulator are available to be sent on-board.

  • Start of all monitoring and control functions before a satellite pass.

  • Acquisition, processing, visualisation if necessary and archiving of the real-time telemetry during the pass. It is used to drive the TC sending when telemetry parameter values must be checked.

  • Sending to the satellite of the TC procedures prepared for the pass.

  • Acquisition, processing and archiving after the pass of on-board recorded telemetry that have been downloaded.

  • Stop of all monitoring and control functions once the pass is finished.

  • Raising alarms that are processed by the control centre during the recorded telemetry processing.

• Offline operations are generally not automatic. The offline operations are, for instance, preparing and validating FCPs, preparing and validating telemetry views, updating the system database, etc….

As a result, except during critical operations or for offline preparation, there is no operator in the control centre. People are on-call and the alarm management software calls them when an alarm is raised.

3.6 Development Industrial Organisation

The development has been given to an industrial consortium leaded by the ATOS company. In this consortium:

• ATOS is in charge of:

  • The system architecture.

  • The system quality management.

  • The security.

  • All functions development except monitoring and control, PUS and flight dynamics functions.

  • The first client mission-specific components development.

  • The AIV of the whole system before delivery to CNES for acceptance tests.

• Thales services are in charge of the monitoring and control and of the flight dynamics functions development.

• Telespazio-Vega is in charge of the PUS components development.

• Spacebel is involved in the automation function development.

• SCASSI gives a support on the security aspects.

• Telespazio has a limited involvement on visualisation and mission operation support functions development.

In this organisation, ATOS is responsible for all the release perimeter building and coordination. Sub-contractors develop and validate the functions they are in charge of, in an environment created and delivered by ATOS. Then they deliver their subsystem to ATOS which is in charge of the assembly of all subsystems and of the complete validation of the various functions through system validation scenarios or functional loops.

3.7 Schedule and First Client Missions

CNES has already received and accepted three releases of the LP CCC ISIS. Two more releases are expected before getting the complete software:

• One in July 2018.

• One in February 2019.

The first client mission is the French defence mission CERES that will be launched by 2020.

The second client mission is the NASA (JPL)/CNES altimetry mission SWOT that will be launched by 2021.

The third client mission is the DLR/CNES methane sensing mission Merlin that will be launched by 2023.

3.8 Expected Benefits from the LP CCC ISIS for Missions

By developing the LP CCC ISIS, CNES expects to reduce the global possession cost of its command control system for the next 30 years. The return on investment is expected to be acquired after the third mission because:

• Specific developments are expected to be very light for each ISIS mission.

• CNES expects to reduce the amount of tests mission after mission, as it will be possible to take into account some validation statuses without replaying all tests.

• CNES expects to reuse procedures from one mission to the other thus simplifying operation preparation.

• It will be possible to optimise the operation teams as the system will be identical on all missions and highly automated.

• After the first three known missions, CNES will have gone through validation of very different kinds of missions allowing to have tested most of the foreseen configurations: a highly secured defence mission in an isolated control centre and two scientific missions in cooperation with other agencies that will be gathered in the same multi-missions control centre.

At the time this paper is written, we have already developed the specific components for the first mission, we have specified the specific components for the second mission and we have a first analysis of the specific components for the third mission. Through those three missions, we have proven that we need around five mission-specific components per mission out of 60 ISIS reusable components. In addition, those specific components are much smaller than the ISIS components. So, we have validated that applying the ISIS standard to our missions gives the expected result in terms of reusability of the LP CCC ISIS software.

As we still are in the development phase, it is too early to have a feedback about the validation optimisation and the operations optimisation but we are confident that our objectives are reachable.

4 Link with EGS-CC

4.1 EGS-CC Brief Presentation

The European Ground Systems-Common Core (EGS-CC) is a European initiative to develop a common infrastructure to support space systems monitoring and control in pre- and post-launch phases for all mission types. This is expected to bring a number of benefits, such as the seamless transition from spacecraft assembly, integration and testing (AIT) to mission operations, reduce cost and risk, support the modernisation of legacy systems and promote the exchange of ancillary implementations across organisations.

The European Space Agency (ESA) discussed with large European System Integrators, including AIRBUS Defence and Space, Thales Alenia Space (France and Italy) and OHB System, the possibility of a collaboration to develop a European Ground Systems Common Core (EGS-CC) which would provide a common infrastructure to support space systems monitoring and control in pre- and post-launch phases. The French and German national space agencies, CNES and DLR also signalled their desire to join the initiative and a Memorandum of Understanding was finalised in support of the EGS-CC initiative.

EGS-CC and LP CCC ISIS fulfil similar objectives and thus exchanges have taken place between the two initiatives. CNES is a member from the beginning of the EGS-CC steering board and of the EGS-CC system engineering team.

ISIS development started before EGS-CC. CNES took part in the EGS-CC system engineering team during the specification phase and brought some inputs from the ISIS data model definition. However, the two data models differ from their perimeter (EGS-CC has a wider scope and addresses wider satellite manufacturing definitions) and from some concepts and data definition.

In addition, a study called ISIS–EGS-CC convergence analysis was performed in 2015 during the EGS-CC phase B to analyse the two systems and see which type of collaboration/convergence could be possible. The analysis covered inter-operability, compatibility, software reuse and cross-fertilisation.

4.2 EGS-CC/ISIS Convergence Study

The convergence analysis aims at identifying potential approaches/measures which would enable:

• Inter-operability: EGS-CC-based applications interfacing with (elements of) the ISIS system.

• Compatibility: both systems supporting the same interfaces to external systems.

• Software reuse: reusing software elements developed for one project in the other one.

• Cross-fertilisation: technology feedback, use of standards, guidelines, etc….

4.2.1 Topics

The convergence has been analysed by addressing the following topics:

• Scope: functional and non-functional features, target applications.

• Concepts: fundamental objectives, approaches, constraints, operational and architectural concepts.

• Data model: semantic level definition of data.

• Product structure: system decomposition, internal organisation and basic architecture.

• Technology: stack of technologies and third party products adopted.

• External interfaces: definition and implementation.

• Standards: adoption, compliance and tailoring.

4.2.2 Functional Scope

The functional scope analysis revealed that:

• The functional scopes are largely overlapping but also complementary.

• The main overlaps are:

  • TM/TC processing.

  • Data management.

  • Automation.

  • Visualisation and reporting.

  • Basic infrastructure.

• ISIS specific features are:

  • Flight dynamics.

  • Memory images management.

  • Station control.

• EGS-CC-specific features are:

  • Separation between monitoring and control modelling/processing and adaptation (e.g. TM/TC) and test facilities. This separation allows to deal with a wide range of applications (e.g. instrument development system to satellite constellation).

• Non-functional requirements are generally comparable or equivalent except:

  • The redundancy approach and design.

  • The software criticality management.

4.2.3 Concepts and Data Model

The basic functions of monitoring and control are the fundamental ones of an M&C system and, therefore, they are common to EGS-CC and ISIS, but there are fundamental differences in the basic system concepts associated to them. Main differences are:

• The monitoring and control model.

• The live, playback, replay and retrieval functions.

• The messages and events.

• The adaptation and deployment.

• The data storage.

• The time management.

The main (but not the only one) driver for these differences is the difference in the scope of applicability (types of missions). Other areas are conceptually more similar. These areas are:

• The components type and approach.

• The TM/TC data management.

4.2.4 Architecture

There are some major differences in the system architecture and structure. The differences brought to light by the study are:

• Infrastructure and communication.

• System integration approach.

• Data access.

• System of systems support.

• Processing distribution.

• User interfaces.

Other areas are conceptually more similar. These areas are:

• The component-based conception.

• The service-oriented architecture.

4.2.5 Technology

There are major differences in the selected technology baseline notably for software development tools. Differences are on:

• Programming language.

• Components and integration framework.

• User interface framework.

• Files management.

Some technologies or products are nevertheless common:

• Inter-process communication is based on ZeroMQ.

• Short-term archive is based on LevelDB.

• User directory is based on OpenLDAP.

4.2.6 External Interfaces and Standards

There are fundamental differences in the approach adopted by the two systems for interfaces and standards:

• EGS-CC defines generic interfaces, adhering to relevant standards where possible. Adaptation to a specific implementation of external systems is target specific.

• ISIS specifies many more interfaces assuming a very specific target.

However, the interfaces implementing international standards can be made inter-operable and/or compatible. The interfaces in this case are:

• TM/TC data definition (E-70-31, XTCE).

• M&C Services (MO).

• TM/TC data (SLE).

4.2.7 Scenarios Evaluation

Possible convergence scenarios have been evaluated according to relevance and feasibility. Only the scenarios scoring at least medium in both criteria are listed below:

• Inter-operability of ISIS FDS and Expert W/S with EGS-CC.

• Compatibility of EGS-CC-based CCS with ISIS.

• Reuse of ISIS communication component (in EGS-CC MO).

• Technology feedback (in particular for MO implementation).

• EGS-CC extensions (communication inspector and media manager).

4.2.8 Convergence Proposals

Finally, considering the results of the convergence analysis, the convergence proposals raised by the EGS-CC Consortium aim at ensuring and verifying compatibility of EGS-CC external interfaces with the relevant ISIS interface (for both inter-operability and compatibility scenarios).

As a consequence of the convergence proposals, there will be the need to exchange technical information about the use of common technologies and standards. The form to achieve these needs to be agreed.

Convergence proposals identified by the Consortium are:

• Definition and support of an import/export format enabling exchange of TM/TC data definitions between ISIS and EGS-CC-based systems (e.g. definitions from an EGS-CC-based EGSE system could be transferred directly to an ISIS control centre).

• Joint development and cross-validation of a ‘CCSDS MO API’ supporting the provider and consumer side of M&C Services. This aims at:

  • Ensuring inter-operability of ISIS and EGS-CC-based systems.

  • Promoting the adoption of CCSDS MO as standardised interfaces for the provision of M&C services on ground.

This CCSDS MO API is currently developed in the frame of the EGS-CC contract.

5 Conclusion

As a conclusion, CNES has initiated around 2007 the ISIS studies. ISIS standard has been used for the first time by a mission around 2009 and now every new CNES mission uses the ISIS standard. A command control product is under development and will be complete by beginning of February 2019. Three client missions exist and CNES expects others in the future. After around ten years, a first ISIS system will have been assembled and made operational. CNES is now on the way to get its return on investment and to widely deploy the LP CCC ISIS software for the various uses it is designed for. CNES and industrial teams work is about to be rewarded.