American Institute of Aeronautics and Astronautics

1

Network Interface System ESA’s Next Generation CCSDS SLE Interface System

T. Ulriksen*, G. Scotti† and C. Müller‡ TERMA GmbH, Europaplatz 5, 64293 Darmstadt, Germany

Dr. C. R. Haddow§ ESA/ESOC, Robert Bosch Straße 5, 64293 Darmstadt, Germany

The Network Interface System (NIS) is the next generation of ESA’s Operation Control Center front-end to the Ground Station network and is a key element of the future ESA Ground Operation System (EGOS). The objectives of the Network Interface System are to create new and modern software using the latest technologies and standards to create highly scalable software that allows inter-communication with other Agencies using CCSDS Space Link Extension (SLE) as well as automation utilizing ESA’s new Mission AuTomatIon System (MATIS) or specialized Telecommands (NIS Throw Events) sent from the Mission Control Systems.

I. Introduction SA is currently in the process of replacing Ground Station equipments, by using the new Telemetry and Telecommand System (TMTCS), which will only support CCSDS Space Link Extension (SLE) services.

Eventually the usage of the existing, largely propriety, protocols such as Mark II, TMP4, STC-2 etc. will be terminated as well as the current Operation Control Centre front-end to the ground station network, the Network Control and Telemetry Routing System (NCTRS).

The Network Interface System (NIS) is the gateway between the Mission Control System and the Ground Station and provides means for TM/TC transfer via the CCSDS SLE specification as well as file transfers from ESA’s Telemetry and Telecommand System (TMTCS) to the NIS.

NIS has been designed to fulfill the future concepts of Spacecraft Operations such as Automation, Multi-Mission support and software reuse of generic low-level components.

II. System Context HE NIS is composed of four components: Manager, Server, Human Computer Interface (HCI) and Configuration Tool.

The Manager is responsible for the set-up and monitoring of the whole Network Interface System. This includes starting and monitoring NIS Server instances as required as well as configuring Service Instances on a specific NIS Server. The Manager is controlled by an operator using the HCI or from an automation system e.g. Mission Automation System (MATIS) via the NIS External Interface or SMF. Furthermore NIS handles the transfer of Telemetry files between the Mission Control System and the Ground Stations (TMTCS). NIS operates on the basis of a single configuration file (configuration data for the complete Network Interface System) as well as the SLE Service Instance Configuration Files (SICF) and File Transfer Configuration Files (FT-SICF). Each of the SICF and FT-SICF files describe the services provided by the system and the given provision period (service availability).

The server(s) provides the Telemetry/Telecommand interface between the SLE Provider (ESA’s Telemetry and Telecommand System, TMTCS, or others) and the Mission Control System. Furthermore they handle specific NIS Throw Events for automation of the system. Multiple instances of the Server process are executed according to needs, each one serving a given Mission and SLE Service.

* Senior Software Analyst, TERMA GmbH, Space, Europaplatz 5, 64293 Darmstadt, Germany † Software Analyst, TERMA GmbH, Space, Europaplatz 5, 64293 Darmstadt, Germany ‡ Senior Software Engineer, TERMA GmbH, Space, Europaplatz 5, 64293 Darmstadt, Germany § NIS Technical Officer, ESA/ESOC, Robert Bosch Straße 5, 64293 Darmstadt, Germany

E

T

SpaceOps 2006 Conference AIAA 2006-5732

Copyright © 2006 by European Space Agency & TERMA A/S. Published by the American Institute of Aeronautics and Astronautics, Inc., with permission.

American Institute of Aeronautics and Astronautics

2

The HCI is a GUI based client application that is used to control the deployed system. It interfaces with the Manager via control interfaces and implements monitoring interfaces to receive state changes. Furthermore it allows a dedicated operator to perform SLE operations on the available Service Instances and monitor the TM/TC Links between the NIS Servers and the MCS. In addition, a window for TM File Transfers from the configured Ground Stations (TMTCS) to the NIS Manager is provided, where the files can be processed offline by the individual MCS’ s.

The NIS Configuration Tool provides the user with the capability of creating/maintaining configuration databases used by the Network Interface System. The Configuration Tool consists of a model that is used by any component accessing configuration data and the tool itself that provides the editing capabilities.

Figure 1 below depicts the Network Interface System context and identifies all external interfaces as provided or used by the NIS applications. The diagram only shows the elements of the EGOS concept that interfaces directly with the NIS, such as MATIS via Service Management Framework (SMF), ESTRACK Management System (EMS), Mission Control System (MCS) and the G/S.

A. Ground Station Interfaces Space Link Extension. The interface to the G/S for TM/TC is implemented using the Space Link Extension

protocol (SLE) defined by CCSDS. TMTCS File Transfer. The TMTCS provides a file-based interface for external users to retrieve TM data files. It

should be mentioned that this facility is not a SLE service and is only available when connected to a TMTCS equipped ESA G/S.

B. Mission Control System Interface TM/TC Interface. The Network Interface System supports the existing NCTRS-MCS interface. NIS Throw Events. The Network Interface System enhances the SLE Throw Event concept by adding a number

of NIS specific Throw Events for controlling and monitoring the system. These Throw Events are typically used in an automation scenario where the automation is executed via a command source.

TM File Transfer. The Telemetry files received from the TMTCS are stored locally within the NIS and made available to the MCS.

C. ESTRACK Management System Interface The interface to EMS allows the delivery of the Service Instance Configuration Files to the NIS. These files are

required in order to handle the SLE Service Instances.

Network Interface System

Manager

SMF

G/S

MATIS

Server

HCI

MCS

EMS

Service Requests/Monitoring Data

Service InstanceConfiguration Files(SICF)

TM/TC DataNIS Throw Events

Monitoring/Control

Monitoring/Control

File TransferService*

CCSDSSLE

Figure 1. Network Interface System context The picture shows the components directly interfacing with the Network Interface System and the subcomponents building the NIS. *The File Transfer Service is only available for ESA’s Ground Stations equipped with the TMTCS.

American Institute of Aeronautics and Astronautics

3

D. NIS External Client Interface The NIS Manager provides an external interface for NIS clients to operate and monitor the SLE Service

Instances, as well as the File Transfer Service Instances for Telemetry data transferring.

E. Service Management Framework Interface The Network Interface System provides a set of services via the SMF middleware that can be used by external

clients such as MATIS.

III. System Design and Technologies IS has been designed and implemented making use of different software technologies (object-oriented software design using polymorphism and modularity) and a specific architectural approach, as described in the

following. The Architectural Design has been mainly driven by the concepts of Multi-Mission support and system

scalability; in fact, the NIS is capable of supporting multiple missions, simultaneously, from a central point, being able to support high throughputs by distributing the load on several physical machines.

Consequently the Manager is the unique process holding the logic for operating SLE Service Instances and TM File transferring for all Missions configured within the system. The Manager is responsible for distributing the load associated with the TM/TC processing on the available hardware. One or more HCI’ s allow the user to operate the NIS either centrally i.e. for operating all configured missions, or locally to a specific mission.

Another important design constraint for the NIS is the demand for extensive software re-usage, inline with ESOC’ s EGOS initiative. Hence the NIS reuses a number of low-level components supplied by the SCOS-2000 Mission Control System software, to implement basic functions. This approach offers many significant advantages: use of robust, reliable and well-proven software components, reduction of development and maintenance costs and, most important, allows the integration of NIS and MCS software on the same hardware. This enables a new possible approach to the combined operational control of spacecraft and ground stations in the same operational environment, as described in section IV below. The most relevant reused components belong to the following areas:

x Task Launcher, used to control and monitor NIS component processes; x User Manager, used for user privilege control; x Event Logging, used to generate and report log messages to the operator, and to archive them; x Process Location Service and CORBA Naming Service, for locating the different applications used by

the Network Interface System, for setting up the MCS interface and for internal use. x MISC subsystem, used to read static and dynamic configuration variables; x Time and Date Subsystem, which provides basic time and date information including leap-year

corrections and simulated time; x Inter Process Communication, supplying high-level TCP/IP functions required by the MCS interface

for telemetry and Telecommand transfer. The system has been developed using a hybrid combination of object-oriented languages: Java for the Manager

and HCI components and C++ for the Server. Java offers the advantage of being platform independent, and is backed by an extensive literature and

development tools including the Eclipse extensible development platform used throughout the development phase. The HCI makes use of the Standard Widget Toolkit (SWT) graphic libraries to ensure common look and feel to the human interfaces displayed on various platform.

Both Manager and HCI make use of JNI technology to access some of the low level components provided by the SCOS-2000 environment. On one hand this represents a limitation to the possibility of running these application on any platform supporting Java, limitation that could be overcome in the future if these components will be re-engineered to provide platform independent interfaces, e.g. by using CORBA.

C++ has been selected for development of the NIS Server, the most critical component of the system in terms of performances, which implements the ESA SLE API libraries also written in that language.

Particular attention has been given in the design of the external interfaces, in order to provide NIS with a high

level of operability. NIS exposes a number of interfaces that allow the system to be monitored and controlled by different sources, very much oriented to provide the NIS with advanced automation capabilities:

N

American Institute of Aeronautics and Astronautics

4

CORBA interface, used by external clients to operate and monitor the SLE Service Instances, as well as the File Transfer Service Instances for Telemetry data transferring. The NIS HCI uses the same interface to allow the local user to operate the NIS.

SMF interface, based on the EGOS Service Management Framework middleware (CORBA based) by which the NIS exposes SLE related services in a generic way to the SMF users. In the context of EGOS, MATIS will use this interface. However, any SMF user can make use of the services provided by NIS.

NIS Throw Event, TCP/IP based, to allow the MCS to operate the SLE connections to the Ground Stations by means of dedicated Throw Events, similar to the SLE Throw Event defined by the CCSDS Standard for operating the Ground Station equipment remotely.

Furthermore NIS offers a TCP/IP based interface towards the MCS for exchanging Telemetry and Telecommand data maintaining the backward compatibility with its predecessor, the NCTRS.

External interfaces have been designed to allow easy enhancement and/or replacement of any of the external interfaces to fulfill specific missions requirements or to implement new standards and protocols. This is an important issue for software that will be used in many years by different missions with different requirements and demands. This means that missions can enhance or replace the existing interfaces without having to change the kernel functionality of NIS and still provide a centralized system control like Ground Facility Control Centre (GFCC).

Another important issue involving the NIS set up and operation is related with the configuration of the system. For this purpose the NIS offers a specific Configuration Tool, an off line java application that guides the user throughout the creation and maintenance of a configuration database, including the validation of the database with respect to a set of consistency criteria.

The configuration database is stored in a XML file loaded by the NIS Manager at start up. For this reason the creation of the database can in principle be also assigned to an external application.

IV. Operational Concepts HE Network Interface System has been developed to support a large scale of different operational scenarios not only to fulfill the environmental and operational requirements of the European Space Operation Center, but also

to allow interoperability with other Agencies utilizing the CCSDS SLE standards, and automation of the system using various interfaces offered by the system.

A. Interoperation with other Agencies One of the main objectives for the Network Interface System has been to replace the existing ESA specific

protocols between Ground Station and Mission Control Systems such as TMP4, Mark II, and STC-2 etc. The NIS implements only the CCSDS SLE standard that is a unique standard used by several Ground Stations around the world not only ESA Ground Stations. The CCSDS SLE services were first utilized for the ESA Integral mission making use of NASA’ s Deep Space Network (DSN) during routine operations, which shows the importance of interoperability between the agencies.

The advantage of the Network Interface System is that it supports the full set of the CCSDS SLE standard and thereby allows a mission to communicate with any Ground Station that supports the SLE standards independently from its provider. This not only simplifies the implementation of the Mission Control System for a new mission but also saves costs because the available Ground Stations across the Agencies may be used in a more efficient way that is currently the case.

The CCSDS SLE standard does not describe which services the Ground Station provides or the availability of the resources. This is managed using the concept of Service Instance that is an agreement between the provider and user, defining the set of services and allowed configuration that a provider supports in a given timeframe. The Service Instances are defined in Service Instance Configuration Files that are typically a product of the Planning facility that defines the availability of the resources. The Network Interface System uses the Service Instances for service agreement between the Ground Station and the MCS and allows the operator or automation system to configure a service based on the definition of the Service Instance.

T

American Institute of Aeronautics and Astronautics

5

B. Automation An important factor for any future software development for the Agency is to allow automation of the services

provided by the software/hardware based on schedules, plans and other configuration items. The Network Interface System supports three different interfaces that may be used for automating the configuration of the services provided by the system:

1. CORBA based External Interface used by the HCI 2. Automation from ESA’ s Mission Automation System utilizing the Service Management Framework 3. The concept of Throw Events specialized for the Network Interface System

1. External Interface

The External Interface is a standard CORBA based interface that exposes a set of operations that allows a client application to control and monitor the system. That is, any SLE services managed by the system in terms of available Service Instances may be configured as well as system monitoring. The External Interface is not thought as an automation interface and is rather complex. It is mainly used by the HCI that allows an operator to manually interact with the system.

2. Service Management Framework

The Service management Framework is a new middleware of ESA’ s infrastructure components that has been designed with the concept of Automation in mind. The Service Management Framework is a generic layer that allows any system to expose services to the outside world via a centralized point. One advantage of this concept is that the service user only has to contact the Service Directory System of the SMF to retrieve the necessary information to initiate a service i.e. establish a link between a Ground Station and a Mission Control System. All services exposed by the system have been defined in a generic way that simplifies the implementation of the client application.

3. Network Interface System Throw Events

The concept of NIS Throw Events was created based on request from a number of ESA missions that are either using different Mission Control System not based on SCOS-2000 or Mission Automation Systems where the Service Management Framework is not available or used. The CCSDS SLE standard already defines the concept of Throw Events allowing the SLE User to configure the SLE Provider directly from a command source. The Network Interface System implements a set of specialized Throw Events (mission customization) that allows fully automation of the system by sending specific Telecommands from a command source. This means that a schedule of commands to control the spacecraft during a pass can be extended to include the complete TM/TC link configuration before the pass, release of the resources after Loss Of Signal and automatic replay of data stored on the Ground Station. This way of controlling the system minimizes the effort for adapting existing systems to make use of the Network Interface System.

Although the system defines a set of default NIS Throw Events, the definition of these and implementation has been implemented in a shared library that can be replaced easily by any mission that may have other requirements.

C. System Deployment The Network Interface System has also been designed with the knowledge of increasing performance

requirements for high demanding missions as well as the increasing usage of SCOS-2000 by other Agencies than the European Space Agency.

The performance management is implemented by allowing the operators (by static configuration) to decide the

physical hosts that are involved with the processing of the Telemetry and Telecommands. By this, it is possible to calculate the overall load on a specific host and split the processing on a number of physical machines necessary to process the high load and at the same time guarantee a safe operation. The possibility of defining the physical machines involved in the processing also allows a complete separation between multiple missions, which is an important factor in Multi-Mission configuration where no single failure should have an impact on the running system for other missions.

The other aspect of deployment is how the Network Interface System can be installed and configured. The

system is using a set of low-level services provided by SCOS-2000 and can be configured as an extension to an

American Institute of Aeronautics and Astronautics

6

dd Multi-Mission Operations

General Domain

Domain 1 (Integral)

Domain 2 (Rosetta)

HCI (Integral)

Serv erServ er

Server

Serv erServ er

Server

HCI (Multi-Mission)

Manager

Figure 2. Multi-Mission Operations The picture shows how the Multi-Domain concept of SCOS-2000 is used to allow Multi-Mission support for the Network Interface System.

existing Mission Control System based on SCOS-2000. This limits the costs and complexity of the Mission Control System and Ground Station interface and furthermore allows the single Spacecraft Operators to manage the TM/TC links to the Ground Station from the same system as used to control the spacecraft operations. For large scale Agencies where the Ground Station operations are maintained by a dedicated G/S facility i.e. GFCC, the Network Interface System can be deployed with a “thin” version of SCOS-2000, allowing one or more operators to control all interfaces to the Ground Stations. Basically this is a standalone distribution of SCOS-2000 with only the limited low-level components used by the system. In this configuration a single operator may control and monitor the links for several missions to any of the Ground Stations that are used by the missions. This type of operation is what ESA’ s GFCC is using.

D. Multi-Mission concepts The term Multi-Mission means that one instance of the Network Interface System is capable of supporting

multiple spacecrafts or missions. This is achieved using the concept of Multi-Domain offered by SCOS-2000, where each domain represents a spacecraft or mission. Generally there is no data exchange or connection between the missions except for the Manager that controls all server applications. The Manager is, however, only used during link configuration and doesn’ t present a single point of failure for all missions as the actual server applications continue normal operation even when the Manager is not available.

Using the SCOS-2000 environment for the support of multiple missions/spacecraft, allows different kinds of users to access the system each having their own restrictions to the system. Running the HCI from a particular domain will allow the Spacecraft Operator to access only those links that are involved with the mission/spacecraft associated to that domain. Running the HCI from the General Domain allows the operator to monitor and control all links of any domain defined by the SCOS-2000 installation. This configuration is currently used at ESOC where each Spacecraft Controller (SPACON) can monitor (and control) the links to the Ground Stations for their mission only, and the Network Operators from the GFCC can operate the links for all missions.

V. Conclusion HE Network Interface System has been delivered to ESA/ESOC in March 2006. The NIS is expected to replace the existing Network Control and Telemetry Routing System (NCTRS) by the end of 2006 and will be used in

the configuration required by the missions i.e. integration with the Mission Control System or as standalone system controlled by the Ground Facility Control Centre.

As part of the preliminary acceptance testing, a demo was made using the automation capabilities of the system for controlling and monitoring the TM/TC links to the Ground Stations as well as monitoring the status of the Ground Station using the SLE Provider Status Reporting mechanism. The demonstration showed how powerful the automation interfaces are for fully automating the interface to the Ground Station for both single- and multiple missions. What the demo also highlighted is how the automation interfaces can be used for automatic testing of the system, which is one of the key elements in ESA/ESOC’ s new generation of operational software. A number of items that require human intervention e.g. HCI, cannot be tested using this function. However, since the HCI and automation tools are making use of the same interfaces, the testing of the external interfaces, kernel functions and CCSDS SLE services can be fully automated and only the HCI has to be tested manually.

T

American Institute of Aeronautics and Astronautics

7

The following design changes and enhancements have been discussed during the development phase: 1. The three different interfaces supported by the Manager component (CORBA, SMF and Throw Events)

not only differ in the usage but also in the way they interact with the kernel. It is currently being investigated if this should be changed to make the kernel more generic and exposes the services to an “adaptor” layer that performs the translation between the different interfaces supported by the system. The adaptor layer will provide a factory that can be used by the user applications for creating service request for any of the interfaces and provide an adaptor for converting the request into the generic requests used by the kernel. This enhancement will not only simplify the maintenance of each interface and kernel, but also minimize the design and development cost if new specialized interfaces are required.

2. Automatic testing of all services provided by the system. The automation interfaces will be extended to provide all services that are exposed by the Manager. This will allow a fully automated testing of the system with the exception of the HCI. The test agent is a simplified automation system much like the ESA/ESOC’ s Mission Automation System that runs a list of schedules. A schedule defines the services to be tested, the interface to be used (CORBA, SMF, Throw Events etc) and the absolute or relative time where the service is requested. Each request will define (optionally) the expected result that is validated to verify the success of the service.

References Ref 1) EGOS Generic Software Requirements, EGOS-GEN-GEN-SRD-0001, 1.1, 05 October 2004

Ref 2) Tailoring of ECSS Software Engineering Standards for Ground Segments in ESA, part A, B and C, BSSC 2005(1). - 1.0, June 2005.

Ref 3) Space Link Extension – Forward CLTU Service Specification, CCSDS 912.1-B-2, Blue Book, November 2004

Ref 4) Space Link Extension – Forward Space Packet Service Specification, CCSDS 912.3-B-1, Blue Book, November 2004

Ref 5) Space Link Extension – Return All Frames Service Specification, CCSDS 911.1-B-2, Blue Book, November 2004

Ref 6) Space Link Extension – Return Channel Frames Service Specification, CCSDS 911.2-B-1, Blue Book, November 2004

Ref 7) Space Link Extension – Return Operational Control Fields Service Specification, CCSDS 911.5-B-1, Blue Book, November 2004

Ref 8) Design Patterns: Elements of Reusable Object-Oriented Software, ISBN 0201633612.