Cortex SLE Provider System From prototype, to product, to successful operations

Transcription

1 SpaceOps 2006 Conference AIAA Cortex Provider System From prototype, to product, to successful operations C. Laroque * VEGA, Darmstadt, Germany D. Firre and K.J. Schulz European Space Agency, European Space Operations Centre, Darmstadt, Germany and P. Clauss IN-SNEC, Paris Les Ulis, France The integration of CCSDS Space Link Extension () interfaces to the Cortex system was done in several steps, where the first step was to develop a simple prototype aiming to demonstrate the feasibility of adding interfaces to non- interface system at reasonable cost. The prototype was developed in 1996, at the time the ESA API was developed. The prototype performed the mapping between the Cortex and CLTU and RCF interfaces. Configuration was limited, and only online timely return interface was provided. Since the prototype clearly showed that integration of interfaces to the Cortex system was possible, and since no provider system was yet available on the market, it was decided to upgrade the prototype to a real product, the Cortex Gateway that can be used operationally. Operational usage of this Cortex Gateway started in As the performance was proven to be very successful, and the system allowed cost effective modernization of the ground station equipments, it was decided to replace baseband installation with the Cortex system including the new capability. However, the system had still some limitations and constraints, which became more and more critical as needs for system fully supporting interface increased. At the same time, a new version of the CLTU, RAF and RCF services specifications was released. As a final step it was then decided to fully integrate the Cortex Gateway into the Cortex system itself and to upgrade it to fully support the latest service specifications. This integration phase carefully took into account the operational needs and requirements, in order to provide a compact, integrated and easy to use system. The first operational tests clearly showed the advantage of the new integrated system: single compact and relatively small system, easy configuration, better monitoring and control allowing easy operations, better support and flexibility. This paper presents the operational success of the new Cortex provider system within the ESA tracking network (ESTRACK), and shows how taking into account operational needs in the early phase of the project is a key point for operational success. The paper describes the Cortex provider system, and the evolution from the prototype to the final product. It shows how reuse and upgrade of software components can lead to successful operational systems for current and future operations. * Consultant, Space Division, VEGA IT GmbH, Robert-Bosch Strasse 7, Darmstadt, Germany. Station Engineer, Mission Operations Department (OPS-O), ESOC, Robert-Bosch Strasse 5, Darmstadt, Germany. Head of ESTRACK Network Configuration and Test Section, Mission Operations Department (OPS-O), ESOC, Robert-Bosch Strasse 5, Darmstadt, Germany. IN-SNEC, 5 Avenue des Andes, Z.A. Courtaboeuf, BP 101, Les Ulis Cedex. Copyright 2006 by VEGA Group PLC and European Space Agency. Published by the American Institute of Aeronautics and Astronautics, Inc., with permission. 1

2 I. Introduction At the time the ESA Application Programming Interface (API) was developed in 1996 by ESA/VEGA, a prototype of provider has been implemented in order to demonstrate the feasibility of adding CCSDS interfaces to non- interface systems at reasonable cost using the API. This provider system has been implemented on the Cortex system since this system provides a simple and easy to use TCP/IP interface which provides access to all its parameters, and allows transfer of telemetry and telecommand data at frame and Command Link Transmission Unit (CLTU) level. The Cortex is a Command Ranging & Telemetry Unit which provides satellite telemetry and telecommand processing and satellite ranging at Intermediate Frequency (IF) and baseband level. The Cortex which is a PC-based architecture with Windows operating system, provides a -friendly and intituitive graphical interface for monitoring and control, and interfaces to the Mission Control Centre (MCS) via a proprietary TCP/IP interface. II. From a Prototype to an Operational Gateway The architecture of the prototype was driven by the fact that the Cortex system was a legacy system, to which interfaces should be added without modification of this system. The prototype was then designed as a gateway sitting between the Mission Control System (MCS) and the Cortex system, and translating the interfaces to the Cortex interfaces. The first step was to clearly define and specify a mapping between the Space Link Extension () interfaces and the Cortex interfaces. As part of this step, the information provided by Cortex on its monitoring and control interfaces, and the internal processing of telemetry and telecommand data was analyzed. The result of this phase was a clear mapping, defining the role of each system (prototype and Cortex signal processing system), and specifying how the prototype would map the two different interfaces. Due to the fact that the exercise was to demonstrate the feasibility of adding interfaces to the Cortex system, the scope of the prototype was limited, and only mapping between the Cortex and CLTU and RCF (Return Channel Frame) interfaces was provided. In addition, the configuration was limited, and only online timely return interface was provided. Since the prototype was successfully implemented and tested, and since no provider system was yet available on the market, it was decided to upgrade the prototype to a real product, the Cortex Gateway that could be used operationally. A. The Cortex Gateway The Cortex Gateway (CSGW) interfaces on one side to the Cortex system via the Cortex TCP/IP interface, and on the other side to the mission control centre via RCF and CLTU interfaces. CSGW takes incoming operations, forms a Cortex specific request and passes the request to Cortex. On the other hand, the gateway takes messages from Cortex and forms specific operations, which are in turn sent to the. CSGW was designed to be a gateway executing on a separate computer running on Microsoft Windows. The technical approach for the mapping between the Interface and the Cortex interfaces is CORTEX Signal Processing System Cortex Tables CTRL TM TC MON LAN I/F TCP/IP TCP ports CORTEX MMI CORTEX Gateway RCF provider CLTU provider CORTEX Gateway MMI API Package CSGW Config LAN / WAN Figure 1. CORTEX Gateway Overview Mission Control System RCF CLTU 2

3 illustrated in Fig. 1. The Cortex provides access to specific data flows via TCP/IP using a simple messaging protocol. Each type of data flow is allocated a specific TCP port number. The CSGW interface-mapping application consists of a set of providers and communicates with the Cortex using the telemetry and telecommand data flows via standard TCP sockets. For some parameters required by specifications, CSGW retrieves the information via the monitoring data flow. Set-up and configuration of the Cortex system makes use of the standard Cortex man machine interface, whereas the configuration, monitoring and control of CSGW is achieved via a dedicated MMI. The CSGW comprises two simple service provider applications for the services RCF and CLTU. These applications communicate with service applications via the ESA API. The RCF provider application receives telemetry frames from Cortex, extracts the required parameters from the message header, constructs the protocol data unit (RCF-TRANFER-DATA invocation), and forwards it to the application. The Cortex provides a dummy telemetry message which are used to detect loss of frame lock and generate the notification required by. Additional parameters, such as the demodulator lock are obtained from the monitoring data flow. The CLTU provider application receives CLTUs from the application via the API. It implements the CLTU buffer required by and forwards the CLTUs to Cortex via a Clear Satellite TC request when the radiation start time is due. The Cortex provides an acknowledgement message, which is examined and used to generate the notifications on success or failure. Configuration of the CSGW is not achieved via standard Cortex configuration mechanisms, but via several configuration files: The CSGW Configuration File which contains the main configurable parameters; The Service Element and Proxy Configuration File which provide the API configurable parameters; The Service Instance Configuration Files which provide the service specific configurable parameters. B. Cortex Gateway Operations Operational usage of the Cortex Gateway started in 2002, with usage of the system at the ESA transportable ground station (TS-1) in Villafranca for support of the MSG-1 Launch and Early Orbit Phase (LEOP) and 3 months of routine phase operation by ESOC. As the performance was proven to be very successful, and a cost effective modernization of the Malindi station providing internationally agreed interfaces for telemetry and telecommand was required, it was decided to replace the Malindi baseband installation with commercial-off-the-shelf IN-SNEC Cortex systems including the new capability. Its first operational use was for the MSG-2 LEOP in 2005 and the next usage is planned for the Metop-1 LEOP mid In parallel the Cortex system was successfully used for Metop-1 spacecraft system validation tests with the ESOC Mission Control System. After several months of operations and usage of the Cortex Gateway, it was possible to draw some conclusions on the system: The system proved to be very reliable and provided good performances; The system allowed cost effective modernization of ground station backend equipments; The provided limited interfaces demonstrated that mapping of interfaces to Cortex interface was possible and could be used operationally. However, the fact that CSGW was designed as a pure gateway had some impact on the day-to-day operations. Lack for integration was the biggest drawback of the system, which render operations more complicate since two nearly independent systems had to be operated. In particular, the following constraints were outlined: The CSGW and Cortex were two independent systems, that had to be started and stopped separately; The CSGW was using the API Communication Server which also had to be started and stopped separately; The configuration of the CSGW was achieved via separate configuration files, not following the standard Cortex mechanisms; The monitoring and control of CSGW was done via a separated dedicated MMI, different from the one of the Cortex system; No possibility for remote operations of the CSGW was provided. 3

4 C. Lessons learned on the gateway The lessons learned by using the Cortex Gateway were: 1) Adding interfaces to the provider system using a gateway is a cost effective solution, which allow to add interface at low cost and in an effective manner; 2) Using a gateway allows adding interface to a provider system in short time period; 3) Not all functions defined in the interfaces can be provided using a gateway, or implementation of these functions requires important effort. In particular, timing and buffering problems may occur when a gateway interfacing to the provider system via TCP/IP is used; 4) Using a gateway add yet another system in the loop between the ground station and the mission control system. This additional system needs to be installed, maintained, operated separately which lead in the long term to cost increase. From these lessons, the rationale for the development of a new integrated system was established. The new system need to be fully integrated, where the interfaces are provided directly by the Cortex unit and not via a dedicated gateway. Installation, configuration, monitoring and control must be integrated in order to allow easy operations. Ease of operation must be a driving factor in particular for the configuration and operation of the interfaces. In addition, the new system must remove the limitations and constraints of the gateway, since these limitations become more and more critical as needs for system fully supporting interface increase. At the same time, support for the new released version of the CLTU, RAF and RCF services specifications must be provided. III. The Integrated Cortex Provider System A. System Overview The new Cortex Provider System implements a interface application providing RAF, RCF and CLTU interfaces. The interface application is developed as a functional unit of the Cortex and is fully integrated within the system. The interface application is started and stopped with the Cortex system, its configuration makes usage of standard Cortex mechanisms, and it can be monitored and controlled via the Cortex MMI. All interface application parameters are included in the Cortex tables and files which offer the possibility to monitor and control the interface the same way as the other functional units. Figure 2 provides an overview of the new Cortex Provider System. Signal Processing System CORTEX Provider System Interface Application RAF provider I/F RCF provider I/F CLTU provider I/F API Package LAN/WAN Mission Control System RAF RCF CLTU CTRL MON Cortex Tables CORTEX MMI Figure 2. CORTEX Provider System Overview 4

5 B. Interface Application (IA) The Interface Application provides the following main features to the Cortex system: Management of service instance configuration file (SICF); Management of service instances; Interface to the API; Monitoring of parameters provided by the signal processing system for setting of service provider parameters; Mapping of services (RAF, RCF & CLTU) to the signal processing system interfaces; Online timely and online complete delivery mode for Return Services (RAF & RCF); Offline delivery mode for Return Services (RAF & RCF); Logging and tracing of related processing to trace and log files. C. Service Instance Configuration File Management The Interface Application uses Service Instance Configuration Files (SICF) in order to manage service instances; one file contains the description of one service instance. The IA provides an automatic processing of SICF, where a SICF repository is periodically scanned in order to detect new files, which are then read and processed. Errors detected in SICF are logged and invalid SICF are automatically archived or deleted. The IA then provides as monitored parameters the list of available SICF for display in the MMI. The IA also offers functions to delete a SICF file and to scan the SICF repository on-request. The Cortex system is not responsible for creating and copying SICF files. D. Service Instance Management and processing The IA is able to create and load several service instances of different service types (RAF, RCF and CLTU) concurrently. At loading time, the IA reads the service instance parameters from the SICF file and initialize the service instances. Each service instance is handled individually form the others. The IA can handle service instances using version 1 or 2 of the specifications. For return service instances (RAF and RCF), the three delivery modes defined by are supported: online timely, online complete and offline. When online-complete delivery mode is used, an online transfer frame buffer the size of which is configurable is used. This buffer is managed at the service instance level, i.e. several buffers can be created if several service instances run in parallel. The online buffer is implemented as a circular file stored on the local disk. For return offline services, the IA uses the file storage mechanism provided by the Cortex system. The IA requests the signal processing system to send telemetry data read from files stored on the local the disk. The Cortex system always provides as monitoring data the list of loaded service instance. Moreover, it provides commands in order to abort and un-load a service instance. When a service instance reaches the end of the provision period, or when the unbind a service instance with the reason set to end, the service instance state is set to expired, and the service instance is automatically un-loaded. For each service instance, the service instance state and the service instance sub-state are provided for monitoring. The service instance state can take the following values: SICF The service instance configuration file (SICF) has been detected and the service instance is waiting for being loaded; loading will commence when requested from the MMI. Loaded The service instance has been loaded, but the provision period has not yet started. The service instance is not yet able to receive BIND invocations. Running The service instance has been loaded, its provision period has started and the service instance is ready to receive a BIND invocation from the. When the service instance is bound, data transfer is possible and can commence after the START invocation has been processed successfully. Expired The service instance provision period has ended. The state is also set to expired when the service unbinds with the reason end. 5

6 The status running is divided into sub-states, which reflect the Service Instance states as defined by CCSDS. Fig. 3 shows the split of the status running into the Service Instance states and the state transitions depending on the received operations. The service instance can be in the following Service Instance states: Unbound The service instance provision period has started and the service instance is ready to receive a BIND invocation from the Service. Bound The service instance has accepted a BIND invocation and the service system is bound to the service instance. The Service Instance is now ready to accept and process a START invocation. Active The service instance has accepted a START invocation and the service is ready to send TC s or to receive telemetry to/from the service instance. Data transfer can commences and is only possible in this state. E. Forward Interface (CLTU Service) The Cortex system fully supports the CLTU service version 1 and 2 as defined by the CCSDS specifications (Ref. 5, 6), with the exception of the CLTU-THROW-EVENT operation and related notifications which are not supported. The IA maintains the CLTU production status independently for every Cortex telecommand unit and sets its value as described below. Changes in the production status are notified to the as defined by the CLTU Specification. The Cortex system is able to manage the PLOP-1 and PLOP-2 operation modes, and sets the production status accordingly: PLOP-1 The IA does not check the TC encoder status for the setting of the production status. In this case, setting of either bit-lock-required or rf-available-required to TRUE for a service instance is considered a configuration error (the loading of the service instance is rejected). PLOP-2 The IA checks if the uplink carrier is being modulated. If this parameter indicates that the uplink is not modulated, the production status will remain in CONFIGURED state. Start of uplink modulation must be initiated from the MMI. If either one of the parameters bit-lock-required or rf-available-required are set to TRUE, the IA additionally checks that the corresponding bits in the CLCW are set. The IA also maintains the uplink status and check this status before uplink of CLTUs. In order to set the uplink status, the IA reads the bit-lock-required and rf-available-required parameters configured for the service instance, and performs monitoring of the CLCW received on the downlink. The transmission of CLTUs to the signal processing system for radiation is subject to the following constraints: If bit-lock-required is TRUE, CLTUs will only be transmitted when the uplink status is nominal. If rf-available-required is TRUE, CLTUs will only be transmitted when the uplink status is either nominal or no bit lock. If either rf-available-required or bit-lock-required are set to FALSE, CSGW does not read the CLCW from the telemetry flow, and sets the uplink status to unknown. In this case, the IA does not check the uplink status Service Instance States during sending of CLTUs. The IA internally manages a CLTU buffer which size is configurable, and provides the available CLTU buffer size to the service. The available CLTU buffer size is updated when a CLTU is received from the, or when a CLTU is removed from the buffer after radiation. The IA blocks the CLTU service instance in case radiation of a CLTU fails, or the production status is set to halted, or the production status is interrupted while a CLTU shall be radiated. To clear the blocking state, the service must Delete SICF Load SI SI Provision Period Starts SI Provision Period ends / UNBIND - end Delete SICF SICF Loaded Running Expired Unload SI PEER ABORT Service Instance Sub-States BIND START Unbound Bound Active Figure 3. Service Instance Status and States UNBIND PEER-ABORT STOP 6

7 invoke a STOP operation followed by a START operation. Finally, the IA supports specifications of delay between CLTUs (delay between CLTUs with a time resolution of 10 microseconds are supported), and earliest and latest radiation time. F. Return Interface (RAF and RCF Service) The Cortex system fully supports the RAF and RCF services version 1 and 2 as defined by the CCSDS specifications (Ref. 1-4). All delivery modes (online timely, online complete and offline) are supported. For online complete delivery mode, the IA uses a separate online frame buffer for every service instance, which consists of a cyclic file stored on the local disk. The IA sends a telemetry request to the signal processing system, then receives and processes the frames. The IA always requests all frames and de-multiplexes virtual channels internally. Each service instance is bound to one Cortex telemetry unit (the Cortex system supports up to 8 telemetry units). The IA handles telemetry conforming to the CCSDS Packet Telemetry Recommendation (Ref. 7), or transparent telemetry. Besides supporting the Services RAF and RCF, the IA extracts the CLCW from telemetry frames and makes the uplink status (value of the no-bit-lock and no-rf-available flags) available to forward service instances. The IA maintains the return production status independently for every Cortex telemetry unit. Changes in the production status are notified to the as defined by the RAF and RCF Specification. For RAF service, the may select transfer of good frames only, erred frames only, or transfer of all frames. Good frames are delivered by the IA without Reed Solomon symbols whereas erred frames are delivered with Reed Solomon symbols. The synchronization marker is never delivered. The IA always provides the frame annotations as specified by the standard: Figure 4. Cortex Monitoring and Control Displays The earth-received time which can be adapted by specification of a configurable offset; The configurable antenna identifier; The data link continuity; The frame quality. G. Configuration, Monitoring and Control The IA gets its configuration parameters by several means: From the Cortex registry for static parameters which are not likely to be changed. Via configuration commands sent by the signal processing system. These commands are used for IA dynamic parameters, or static parameters which are likely to be changed by operators. From SICF for service instance specific parameters. As the interface is fully integrated in the Cortex system, the Cortex concepts for monitoring and control also applies to the interface. The control commands sent by the Cortex MMI or by a remote system connecting to the Cortex via the standard M&C interface are received and processed by the interface application. In addition, the interface application provides access to its monitoring information via tables also accessible via the standard M&C interface. 7

8 H. Logging and Tracing The interface application stores log messages in log files created under a configurable log repository. One log file is created each time the Cortex system starts. The maximum size of the log file, and the maximum number of log files are configurable. Log files are text files, which contain log messages allowing getting an overview of the IA processing, and checking any detected error or alarm. The log messages generated by the API are also stored in the log files. This allows for example checking connectivity problems between the side and the Cortex system. Each log message is recorded together with the date and time, and the log type indication (info, warning, alarm).. The interface application also provides a tracing function allowing extensive tracing of the IA and API processing. The tracing is mainly used for problem investigations on the interface. The tracing information is controlled via the setting of the trace level. Logging and tracing can be enabled and disabled via commands. I. Performances The Cortex system supports the following performance figures for the interface: Up to 40 service instances can be loaded simultaneously; Up to 8 active return link services and 1 active forward link service can be supported concurrently; Return link service instances with online and off-line delivery modes can be supported concurrently; On the forward link, a throughput of up to 256 kbits/s is supported; On the return link, a throughput of up to 3 Mbits/s is supported for a single service instance. IV. Operations The new Cortex provider system is already installed at the Malindi, Kiruna, and Maspalomas ESTRACK ground stations. The system will support as prime the ESA-ENVISAT mission, and will also support the Eumetsat-METOP mission, the DLR- TERRASAR-X mission, and the ESA-ERS2 mission after migration of the control centre to interfaces. The Cortex provider system was already used for several LEOPs and will for instance be used for the LEOP in 2006 of the Eumetsat-METOP and DLR- TERRASAR-X. Figure 5. Cortex System The Cortex is an elegant and compact product providing all the basic services for telemetry and telecommand. It can be used for Packet missions as well as for PCM missions. The design is robust and relatively simple to configure and to use, taking all advantages from the native Cortex interface V. Conclusion For the development of the new Cortex provider system, the operational needs have been taken into account at the early phase of the project, starting at the specification phase. During the whole project development, design decisions and trade offs have always been considered regarding the operational aspects. Big efforts have been made to provide a system that can easily be used and configured, and that provide easy to use, intuitive and suitable man machine interface. In addition, experience on the preceding Cortex prototype and gateway, and the experience VEGA has acquired since many years on development of and provider systems allowed designing a compact and robust interface. The integration of the configuration, monitoring and control interface, the modification of the Cortex signal processing system performed by IN-SNEC brought the final touch for this new integrated system. In the course of this project, one interesting aspect was also the ability to compare afterward the differences between integrated system and gateway. Provided the target system allows mapping to interfaces, development of gateways is at the first place a simple and cost effective solution; however, on the long term, integrated system shows their benefit in particular for support of services and on the operational side. 8

9 References 1 Space Link Extensions Return All Frames Service Specification. Recommendation for Space Data Systems Standards, CCSDS 911.1, R1.7, Sep Space Link Extensions Return All Frames Service Specification. Recommendation for Space Data Systems Standards, CCSDS 911.1, B2, Nov Space Link Extensions Return Channel Frames Service Specification. Recommendation for Space Data Systems Standards, CCSDS 911.2, R1.7, Sep Space Link Extensions Return Channel Frames Service Specification. Recommendation for Space Data Systems Standards, CCSDS 911.2, B1, Nov Space Link Extensions Forward CLTU Service Specification. Recommendation for Space Data Systems Standards, CCSDS 912.1, R1.99, Feb Space Link Extensions Forward CLTU Service Specification. Recommendation for Space Data Systems Standards, CCSDS 912.1, B2, Nov Packet Telemetry. Recommendation for Space Data Systems Standards, CCSDS 102.0, B4, Nov