ESA Telemetry and Telecommand System (TMTCS)

Transcription

1 ESA Telemetry and Telecommand System (TMTCS) Y.Doat, M.di Giulio, G.P.Calzolari ESA/ESOC Robert-Boschstr.5, Darmstadt Germany This paper describes the future ESA Telemetry and Telecommand System (TMTCS) that will be installed in the Ground Stations of the ESA s Network (ESTRACK). The TMTCS will provide SLE standard services to the Users. The implementation of such services will ensure inter-operability of the ESA stations with the Control Centers of other organizations. 1 Introduction The European Space Agency (ESA) initiated the design of a new generation of Telemetry and Telecommands System (TMTCS) for the network of ESA Ground Stations. The new generations is required as from year 2005 primarily for the following reasons: The TMTCS equipment will support the CCSDS Space Link Extension (SLE) standards, defining the Stations to Control Center services/interfaces. The implementation of SLE Services will ensure inter-operability of ESA stations with other organizations Future ESA missions will require functions and/or performance levels which cannot be supported by the current TM and TC systems This paper focuses on the implementation of the SLE Services in the TMTCS. 2 SLE Transfer Services The Consultative Committee for Space Data Systems (CCSDS) has developed a set of Recommendations that define formats and protocols for the exchange of data between a space vehicle and a ground station. These Space Link protocols are designed to work efficiently in the noisy, potentially high delay environment of space/ground radio links. Thus they are not geared towards conveying space link data within ground systems encompassing at least ground stations and mission control systems. Within its Panel 3, CCSDS has also developed a set of Recommendations complementing the Space Link Recommendations with a range of services that are required to access the space link formats in a uniform way: the Space Link Extension (SLE) transfer services. These transfer services require that the service providing entity can be configured and supervised. This is accomplished by means of the SLE Management services reference model. The Space Link Extension (SLE) Services extend the forward Telecommand (TC) and return Telemetry (TM) services defined by the Consultative Committee for Space Data Systems (CCSDS) (see Figure 1: Ground Stations Provide SLE Services to Users, as provided in [SLE-OV]). Many space missions use the forward TC and return TM services on the space link between ground stations and spacecraft. 1 of 8

2 Forward TC Return TM Space Link Extension Services Figure 1 Ground Stations Provide SLE Services to Users (courtesy of CCSDS) The SLE Services include two major elements: Transfer services that move space link data units between ground stations, control centers and end-user facilities; Management services that control the scheduling and provisioning of the transfer services. The SLE Services operate in two phases: The definition phase, when most of the management activities take place; The utilization phase, when the data transfer takes place (this can be either in real-time or delayed with respect to the contact time with the spacecraft). The SLE Services will carry all types of space data including, for example, spacecraft commands in the forward direction and science data in the return direction. In addition, the services will convey information such as TM data reception times and ground station configuration information. 2.1 Return Services The return SLE Services associated with TM include: Return All Frames (RAF), which provides a complete set of TM frames from a single space link symbol stream to spacecraft operators and other users who might need all the frames; Return Channel Frames (RCF), which provides Master Channel (MC) or specific Virtual Channels (VC) extracted from a particular RAF channel, as specified by each RCF service user; Return Frame Secondary Header (RFSH), which provides MC or VC Frame Secondary Headers (FSH) extracted from an RAF channel, as specified by each R-FSH service user; Return Operational Control Field (R-OCF), which provides MC or VC Operational Control Fields (OCF) extracted from an RAF channel, as specified by each R-OCF service user; 2 of 8

3 Return Space Packet (RSP), which enables single users to receive packets with selected Application Process Identifiers (APID) from one spacecraft VC. Figure 2 shows the data transfer interfaces for these services. All Frames R-AF R-AF Channel Frames R-CF R-CF R-FSH Packet R-OCF R-SP Users From Spacelink Figure 2: Conventional Return SLE Services are Produced in Three Stages (courtesy of CCSDS) 2.2 Forward Services The forward SLE Services associated with conventional TC include: Forward Space Packets (FSP), which enables single users to provide packets for uplink to a spacecraft without needing to coordinate with other users of the spacecraft; Forward Telecommand Virtual Channel Access (FTCVCA), which enables users to provide complete VCs for uplink; Forward Telecommand Frames (FTCF), which enables users to supply TC frames to be transformed to Command Link Transmission Units (CLTU) ready for uplink; Forward Command Link Transmission Unit (F-CLTU), which enables users to provide CLTUs for uplink to spacecraft. Figure 3 shows the data transfer interfaces for these services. CLTU R-OCF F-CLTU F-CLTU TC Frames F-TCF F-TCF VC and Packet F-TCVCA F-SP Users Towards Spacelink R-OCF Figure 3: Three Stages Approach to Conventional Forward SLE Services (courtesy of CCSDS) 3 TM & TC System The following SLE Services will be provided by the final TM & TC System: Return Link Return All Frames (RAF) 3 of 8

4 Return Channel Frames (RCF) Return Operational Control Field (OCF). Forward Link Forward Space Packet (FSP) Forward CLTU SLE service Provision addresses such matters as when service is provided (e.g., service start and stop times), and how service is provided to the User (e.g., which events are notified to the User). Configuration of Service Provision is achieved through Service Instances (see below: Configuration of an SLE Provider). SLE Service is concerned with the actual processing and transmission of TM and TC data units. The TM Processor of the TMTCS will provide the production of Packet TM, AOS, and the old PCM Standard (through the RAF Service). The TC System of the TMTCS will provide the production of Packet TC and the old PCM Standard (through the CLTU Service). 3.1 The SLE Application Programme Interface To support the implementation of the SLE services, CCSDS produced a set of recommendations for the implementation of an Application Programming Interface (API). This set of recommendations defines an interface to SLE application programs for exchange of SLE operation invocations and returns between an SLE service user and an SLE service provider. The API consists of two distinct layers, the API Proxy and the API Service Element. The SLE Application interacts with the API Service Element using a set of functions. ESA and the Jet Propulsion Laboratory (JPL), with commercial support, have both implemented versions of the SLE Transfer Service API for use initially in the INTEGRAL and ROSETTA missions. The API has been developed on top of TCP/IP for both the Service User role (the Control Center) and the Service Provider Role (the Ground Station subsystems, like the TMTCS). The ESA API is available on Solaris-8 and will be ported on Linux. It has been successfully used by application programs implementing both the SLE Service User and the SLE Service Provider applications. The ESA API supports the following SLE Services: SLE RAF; SLE RCF; SLE CLTU; SLE FSP (initiated development); SLE ROCF (initiated development). 3.2 The Monitoring and Control API Available on Solaris and Linux, this API isolates the subsystem from the ESA Monitoring and Control specificities. Originally this API implemented an OSI 7 layers stack using CMIS/CMIP. Today the API implements a CORBA stack for the transfer of the Monitoring and Control 4 of 8

5 objects. The Monitoring and Control objects follows the ESA Ground-Station Monitoring and Control definition. The TMTCS application is isolated from the Monitoring and Control interface through shared memory. 3.3 System Architecture The TMTCS will be integrated in the ESTRACK ground stations, where it shall be connected to other Station equipment and to the Operations Control Center (OCC). Local and Remote M&C CLCW Flow (non SLE) Internal Comms Flow Internal M&C Flow M&C API Channel Decoding Uplink Modulator Return Link TPS SLE-API Portable Simulator TCS Forward Link Portable Simulator Figure 4 TMTC System Overview CLCW To external TCS SLE Services LAN CLCW From external TPS The following external interfaces are foreseen as shown in Figure 4: SLE Services: Interface to the OCCs will be over the Wide Area Network and will be based on TCP/IP Interface to the Local and Remote Monitoring and Control system (Corba over TCP/IP). Interface to the Channel Decoding System on TCP/IP, over the LAN. Through this interface the decoded telemetry data stream will be fed into the TPS (Telemetry Processor). Interface to the Uplink Modulator, for forwarding Telecommands to the modulation chain. This interface will be either in EIA-422-A with raw data stream, or a private protocol on TCP/IP over a LAN. Interface(s) to the Portable Satellite Simulator (PSS), for test and simulations purposes. The uplink data (Telecommands) will be forwarded over an interface identical to the one of Uplink Modulator (therefore two interfaces can be foreseen, the EIA-422-A and the LAN based interfaces). For the downlink the telemetry data stream will be sent from the TM FTP SLE USER WAN LAN SICF FTP 5 of 8

6 Portable Simulator to the Channel Decoding System, and from the Channel Decoding System to the TMTCS. Therefore there will be, initially, no direct interface from the Portable Simulator to the TPS for the downlink. For the sake of simplicity, the following interfaces are not shown in the picture: ftp retrieval for Telemetry; ftp for SICF delivery; time reference interface. 3.4 Configuration of an SLE Service Provider SLE transfer services need to be scheduled, configured, controlled and monitored. To that end, any SLE transfer service provisioning, also termed Service Instance (SI), must be created on the system and proper management of Service Instances with respect to the current Sub-System status shall be ensured. A full implementation of the management of SLE services is accomplished through SLE Management Services defined by CCSDS in [SLE-MAN]. TMTCS will only provide functionality to support a subset of the SLE Management services, while the full set of SLE Management services will be implemented outside the TMTCS, mainly by the Station Computer (STC), which performs the overall monitoring and control function for an ESA Ground Station. The CCSDS Cross Support Reference Model [SLE-REF] defines a Space Link Session as a continuous period during which an SLE system provides the capability to use one or more physical channels on a space link. The TMTCS is not supposed to know the concept of Space Link Session being this a matter of general ground station management and, as such, this will be handled by the Complex Manager (i.e. the Sation Computer). 3.5 Monitoring and Control To support the Complex Manager, the TMTCS, as part of its M&C aspects, will support the concept of M&C Basic States and Forward/Return Spacecraft Sessions. 6 of 8

7 No SLE Service Provision allowed Any re-configuration allowed Setup Command SSU to go Operable Spacecraft Session Closed Command SSU to go Setup Only Offline SLE Service Provision allowed Re-configuration of Online Services allowed Open Spacecraft Session Spacecraft Session Open Operable Close/Abort Spacecraft Session Offline SLE Service Provision allowed Online SLE Service Provision allowed Re-configuration (generally) not allowed. Figure 5 Spacecraft Session vs M&C Basic States The TMTCS will implement the ESA generic M&C concepts defined for all the elements of the ESA Ground Station. In this context, the TMTCS is identified as a Subsystem managed object. The Subsystem supports the concepts of Administrative State and Basic States. The two constituting elements of the TMTCS, are the Telecommand System (TCS) and the Telemetry Processor (TPS). TCS and TPS are defined as two independent Sub-System Units of the TMTCS Subsystem, each having own Basic States. Being the two Subsystem Units independent from one another allows e.g. provision of Return Services even during a major reconfiguration of Forward Services production, or vice-versa. 4 Development 4.1 EGOS The ESA Ground Operation Software (EGOS) is an initiative attempts to rationalize the development process and promotes: ESA Ground-Segment Service definition; Software component reuse through the ESA ground-system (e.g. logging, MMI, ); Operating System independency ensuring simplified maintenance and future migration. 7 of 8

8 4.2 Planning After an operational validation at ESOC end of 2004, the TMTCS will first be deployed in Cebreros (Spain) early References [1] CCSDS B-1, Return All Frames Service Specification, Blue Book, April 2002 [2] CCSDS R-1.7, Return Channel Frames Service Specification, Red Book, September 1999 [3] CCSDS R-1, Return Operational Control Field Service Specification, Red Book, July 2003 [4] CCSDS R-1.99, Forward Space Packet Service Specification, Red Book, February 2003 [5] CCSDS B-1, Forward CLTU Service Specification, Blue Book, April 2002 [6] EGOS -ESA Ground Operation Software, SpaceOps 2004 Ref.: T2_TU.A of 8