1

Network of Technical Centres for Flight Operations: The Search for Standard Systems

Andrew Monham Rhea System SA Stuart James Cater Rhea System SA

Introduction The Network of Technical Centres for Flight Operations is a European initiative, coordinated by the European Space Agency (ESA), to enhance effectiveness and efficiency in Europe by co-ordination of resources to secure high quality mission operations and to increase the innovation potential. It aims to improve efficiency and generate savings for member states by:

• Avoiding duplication and maximising reuse of existing systems • Co-operative management of investments • Optimum sizing of overall capacities • Optimised distribution of tasks amongst centres • Joint procurement to improve centre’s bargaining position • Harmonisation of future investments and consolidation of the network

The Working Group instigated to fulfil this objective is made up of representatives of major European national agencies involved in satellite flight operations i.e. ASI (Italy), BNSC (UK), CDTI (Spain), CNES (France), DLR (Germany), NSC (Norway) and SSC (Sweden). The authors of this paper are currently under contract to ESA to assist the Working Group in classifying existing systems and maximising their potential for reuse. This will permit the optimal sizing of capacities and their distribution amongst the different agencies.

Scope of Study The study is to create the Network of Technical Centres “Catalogue of Standard Systems for Flight Operations”, covering all systems related to satellite flight operations in use (or planned) by the participating agencies. This catalogue will:

• Maintain knowledge on all systems related to satellite flight operations in use, or planned by the participating agencies

• Identify the compatibility between these systems • Identify candidates for potential re-use in other agencies.

The Systems to be addressed are defined in the following categories (see Figure 1Figure 1):

• Network Management System • Mission Control Systems • Flight Dynamics Systems • Mission Planning Systems • P/L Data Archiving &Distribution Systems • Satellite Simulator Systems • On Board Software Maintenance Systems

The latter three systems are shown with a grey background in Figure 1Figure 1 to indicate they were a lower priority than the other systems.

2

Figure 1. Scope of Study

ECSS The European Cooperation for Space Standardization (ECSS) is an initiative established to develop a coherent, single set of user-friendly standards for use in all European space activities. Until the inception of this initiative, in 1993, there had been no uniform system of space standards and requirements in Europe. Although the previous standards and requirements were similar, the remaining differences resulted in higher costs, lower effectiveness and in a less competitive industry. The standards are organised into three branches: Management; Product Assurance; and Engineering. The standard of particular interest to this study is ECSS-E-70: Ground Systems and Operations. This standard provides a high level description of all ground segment elements, the domain specific aspects of the associated engineering processes and defines related guidelines and requirements. The advantages of using this standard are:

• It provides a reference baseline for the analysis of Flight Operations Systems • It provides standard terminology • It provides standard concepts for the logical breakdown of systems • It provides an analysis of factors for system re-use

3

Re-usability Criteria Different agencies in the various countries of the Network of Technical Centres have different constraints, although there is of course an element of commonality through the influence and requirements of the European Space Agency as well as through other European bodies active in space related activities. In particular, the role of European standards such as ECSS is becoming of increasing importance in the way space system developments and operations are performed. Nevertheless, the differences in national constraints acting upon Space Operations Centres and the previous generally lower levels of co-ordination that have been undertaken between these Centres means that the Centres have different operational concepts for system development and operations. This may result in significantly different System approaches to what may be a similar mission undertaking. On the other hand, similarities can be expected in some approaches, despite this having been achieved through completely independent means. It was not the role of this Study to analyse in detail the external constraints and culture which shape the Network of Technical Centres’ systems, but it is necessary to understand these cultures and constraints, such that the rationale behind system implementations can be appreciated and so the potential of these systems in other national or European wide environments can be assessed. In recognition of this, the criteria for re-use can be broken down into two categories:

• Technical: These criteria can be objectively assessed against the data provided by each centre.

• Conceptual: These criteria are more subjective in their assessment as they are not easily

quantifiable. However, they do have perceptible impacts on the systems and documentation.

Technical The technical criteria upon which the Study assessed all systems are:

• Comprehensive Functionality The more complete a set of functions a system provides in a re-usable form, the more likely that it will fulfil the requirements of any target installation. This analysis provides an indication of the maximum potential for reuse, but may be limited if the customer does not accept the implementation of the functionality. Experience has shown differences of implementations due to differences in operational culture.

• Adherence to Interface Standards

Implementation of interfaces utilizing standard protocols will greatly enhance the potential for integration with other systems. Examples include: • IP-based protocols • X.25 • CORBA • CCSDS Space Link Extensions

• Configurability

4

All systems require some level of configuration for new ground systems, or new satellites. The complexity of that configuration is driven by the capacity of the system to manage changes through modular designs and parameter driven, or database configuration items. The levels of configurability identified were (given in their order of ease of configuration and control): • Database driven configuration • File driven configuration • Operator-level configuration e.g. environment variables • Developer-level configuration e.g. source code modifications. Another aspect of configurability is the capability to extend the functionality of a system without having to modify the original code. This is achievable by providing Application Programmable Interfaces (APIs). A cautionary note on Configurability is that it can be taken to the extreme where there are too many configurability options, which when combined with poor usability will become a barrier to use by some organisations. In addition, configuration items need to have control checks to ensure the correct configuration is in use.

• Adherence to Development Standards

Implementation of functions using common software development techniques produces code that is well documented, more maintainable and more easily modifiable for new programs. Examples include: • PSS-05-0 • ECSS-E-40 • Rational Unified Process • UML • Yourdon

Note: The latter two are not complete lifecycle development standards, but specific design methodologies. However, use of these types of methodology during specific development phases will improve the re-usability of systems and were therefore considered during the study.

• Code Portability Implementation of platform independent software and using open standards reduces the reliance on set hardware solutions. This reduces another limitation on the reuse of systems. Examples include: • Java • POSIX • Abstraction layers e.g. ACE • Isolation of O/S specific calls as part of the implementation development. Code portability is also dependent upon vendor independence: reliance on a single vendor for a product may not only restrict the number of platforms to which a system can be ported, but also to specific versions of the O/S.

5

• COTS Dependency Although COTS provide cost effective provision of functionality, they can have a restrictive impact on the re-usability of a system for the following reasons: • They can increase the cost of re-using systems within a collaborative environment

such as the Network of Technical Centres • Unless there are several COTS that can provide the desired functionality, they can

make a system be over-reliant on a single product • They may restrict the re-use of the system not only to a specific O/S, but also to

specific versions of that O/S. In a worst-case scenario, it is feasible for one COTS provider to stop supporting an O/S version and another to only support that version.

• Scalability

Ground systems will vary not only in their desired functionality, but also in size. A system that is modular in design and facilitates expansion, e.g. additional workstations, will be more likely to fulfil a customer’s requirements than one that has a more rigid configuration.

• Licensing

The contractual licensing policies for systems implemented for mission operations will play a significant role in the ability to use the system again on other missions, both inside and outside of the owner facility. The Intellectual Property Rights, the availability of source code and vendor independence for long-term maintenance activities are all factors that will influence the re-use potential of a system.

Conceptual The following conceptual criteria are identified as being instrumental in the various approaches to Flight Operations Systems currently existing or planned in the Operations Centres:

• The Centre core activities: whereas some Centres are limited in their mission control activities (with more emphasis on Ground Network support to other agencies), other Centres have a mandate to control a large variety of spacecraft missions as well as providing full end to end services. In addition, some Centres also have core activities to manage the development of mission operations systems while others can only procure from external sources.

• The budgets for internal staff vs. procurement: these budgets reflect the Centres mandate and resulting core activities, with some having a high level of reliance on external industry while others have staffing levels to manage a customisation or development programmes.

• The roles and responsibilities of existing partner organisations: for example, a partner organisation may take responsibility for payload operations or planning, diminishing the functional requirements and capabilities of the systems in the Centre, and implying additional interfaces which are not required in other Centres.

6

• The Centre’s organisational structures: the division of system elements under separate responsibilities may be reflected in organisational structures. One Centre may have separate organisations for Operations Control and AIT EGSE systems. Another Centre with another organisation may have combined these systems e.g. Operations Control Kernel and AIT EGSE Kernel, Operations Kernel and On-Board Software Management. This can be reflected in the tight coupling of systems that may otherwise be stand-alone.

• The role the users of the system have in implementing it. The software process used when the User and the Developer are independent groups is often different from that where they are the same: The former requires a higher level of procedural interchange to ensure the User requirements are fully understood and correctly implemented; the latter does not. This may lead to an implementation that is acceptable when taken in isolation, but will impact the potential for re-use by other organisations.

• The types of spacecraft mission operations existing and planned: some Centres deal with many different types of mission, which can result in internal generic approaches or alternatively a set of concurrent different implementations. Centres that have mainly had one class of mission, e.g. a GEO communications, will not have had the same issues to consider in their system implementation. A result of this is that systems may become tailored specifically to that satellite class, whereas in Centres that consistently have to deal with different platforms, a generic control system approach may have been taken.

• The role of Technical Standards in the Centre: Technical standards affecting interface design are generally followed in Centres where there is no implicit standardisation due to spacecraft heritage (see above point). For example, implementations, using the generic kernel, are easier if the space to ground interface follows the CCSDS TM/TC packet protocols. However, a heritage system that has been operating a series of satellites using specific TM and TC formats over many years, there may not have been the same incentive to enforce such standards.

• The acceptability of risk levels pertaining to mission interruption and degradation: certain missions may be designed to allow a significant level of degradation to the system before degradation occurs at mission level, such as for certain fleet communication satellites, where satellites may be replaced in orbit to continue mission operations without significant degradation. In these cases the equation between risk and cost may result in more efforts to reduce ground operations cost at the expense of risk, than would be the case on a one-off, irreplaceable scientific satellite. Flight operations system design will be affected by this equation, as will levels of automation accepted in the Centre.

Findings The following findings have been abstracted to the extent necessary to ensure Network of Technical Centres confidentiality is maintained.

System Classification During the course of the study systems were identified that fell into three main classifications:

• Bespoke systems built for a specific satellite. These tended to be those procured by an agency whose primary focus was on the operation of the systems rather than the development of them.

• Heritage systems re-used several times for the same satellite family. In these cases the agencies would have a more significant role in procuring, designing and developing

7

systems with a greater level of re-use potential. These agencies usually have a close liaison with the manufacturers of the satellite families they operate. These systems tend to exhibit a balance between configuration capability and specific implementations.

• Generic infrastructures upon which specific customised systems are implemented. These systems are usually, but not exclusively, provided by agencies that have a long-term plan to support a wide range of mission types and satellite families. Other generic systems have grown up through a more retroactive approach where an agency has used its knowledge of previous implementations to introduce generic, rather than specific, functionality in future systems to gradually grow a generic infrastructure.

As the Study has not been privy to any cost information, it has not been possible to evaluate the cost effectiveness of each category. However, it is expected that the Network of Technical Centres initiative will facilitate the re-use of the more generic systems by agencies that would otherwise only have the resources to consider the bespoke solutions.

Role of Standards Within the study two types of Standards have been considered as indicators of re-use potential: Interface; and Development Standards.

Interface The increased use of widely accepted standards (including de-facto ones) has improved the potential for re-use of systems, as the level of complexity involved with interfacing one system to another has been greatly reduced. Indeed, in some modular systems with well-defined module interfaces, it has been possible to re-use individual modules with other systems. Interfaces have been trending towards the IP protocol suite with most agencies moving from X.25 communications between ground stations and operations centres to TCP/IP. Also, CORBA is becoming a more frequently used as systems become more object oriented. The adoption of the CCSDS standards by European satellite manufacturers has great enhanced the re-usability of Ground Stations and Mission Control Systems. It has removed some of the complexity in TM and TC processing as well as provide a standard method for TC transmission verification. The addition of the Space Link Extensions will further enhance the interoperability of ground stations and MCSs as agencies start to offer extension services.

Development Within Europe the PSS-0-05 Software Engineering Standards have been the primary standard used for the development of software for Ground Control Systems and was the most often quoted standard throughout the study. Although it is a prescriptive standard, the variety of its implementation was fairly wide. As the new ECSS-E-40 standard was not used for the implementation of any system reviewed, it is not possible to comment on its effectiveness as a tool to enhance system re-use.

Common Use Standardisation One other area where standardisation is occurring through common usage is in the area of operating systems and software languages:

• Operating Systems are either Unix, or Windows based with Solaris or Linux being the most common forms of the former, and NT or 2000 the latter.

8

• In conjunction with this polarisation of O/Ss comes the use of modern languages that are supported on both these kernels either through the use of a Virtual Machine e.g. Java, or through a wide variety of compilers e.g. C++. An exception to this is the use of Visual Basic for non-real-time tools based on the Microsoft Office environment.

Organisational One area where the influence of organisational structures has been noticeable is in Flight Dynamics Groups. Flight Dynamicists tend to provide a service, rather than a system, to a mission team. As such, they are responsible for the development and operation of the FDS. This method of operating is feasible due to the large overlap in the skill set required for both the operators and developers i.e. The scientific nature of flight dynamics operations requires a level of computer literacy that is on a par with a software developer. The amalgamation of the specification of system requirements, together with the implementation, testing and operation of the system within a single team can lead to modifications in the software development process to permit a quicker development cycle with fewer formal reviews and less documentation. However, for the purposes of this study these modifications restrain the potential for re-use in the following ways:

• Code is written that is understood by the implementer, but does not have the level of structure and commenting necessary to minimise configuration, integration and maintenance effort.

• Documentation is not as extensive, or as organised as in the case where there is a clear division between user and developer.

• The scope of testing is not clearly identifiable as it is performed within a single team in a more informal manner.

Configurability Trade Offs It became apparent during the study that large systems that are highly configurable have a tendency to appear overly complex to integrations teams using them for the first time. This has been especially so for those agencies, which have limited development and maintenance teams. Unless effort is expended in simplifying the installation and use of the system, the complexity barrier will cost as much, if not more, to overcome than procuring a simple bespoke system. Although there are systems within Europe that have the scalability potential to be used for both a single microsatellite to a large fleet of complex satellites, they have not so far achieved the aim of being usable by the less experienced organisations.

Other Issues

Marketing Comparison While performing research for the Study, a review of Ground Control System providers worldwide, it became apparent that US companies were much better at marketing their systems via their web sites. European companies seemed to neglect this form of marketing. Is this due to a belief that they know their complete potential market and can market to them via other means?

Commercial Use of Agency Products This study was about identifying systems for agencies to use. However, another aspect that should be considered is how do the agency’s market the products they generate. Also, a lot of agency owned systems are developed by small companies who do not have the capacity to market

9

effectively on their own. Have agencies considered methods of supporting combined marketing efforts, or providing forums for small companies to market more cost-effectively?

Conclusions The Network of Technical Centres study has found that there already has been a drive towards more reusable systems both by individual agencies and commercial companies. Examples have been identified in the areas of Mission Control, Mission Planning, Ground Station processing and Satellite Simulators. The Network of Technical Centres will promote the increased use of these types of systems over the procurement of outside bespoke systems through the greater interchange of knowledge and cooperation engendered by this initiative. The ECSS is promoting a convergence of management, quality and engineering cultures and concepts that will increase the number of future systems capable of reuse. However, there are still barriers to maximising the amount of reuse between agencies:

• National agencies have a role in supporting their own industry. Therefore, the configuration, integration and maintenance of generic systems must not be limited to a few companies.

• Individual programs need to provide cost effective solutions within their budget allocations. Therefore, the generic solutions must be competitive with bespoke solutions in terms of both procurement and operational costs.

• Procurement philosophy: Many agency programs are single contracts with the satellite manufacturer to provide a turnkey solution over which they have full control. Separating out the procurement of the ground system will increase the complexity of the procurement, but will permit greater flexibility in the choice of systems.