- Email: [email protected]
Telematics Applications for the Remote Control of Space Missions
Copyright @ IFAC Telematics Applications in Automation and Robotics, Weingarten, Germany, 2001
TELEMATICS APPLICATIONS FOR THE REMOTE CONTROL OF SPACE MISSIONS
Paolo Ferri
European Space Agency / European Space Operations Centre RBosch Strasse 5, D-64293 Darmstadt, Germany
Abstract: Telematics plays a major role in space exploration, as all space missions involve remote control from ground. In addition, some control loops can be closed on-board, by human beings for manned missions, or by automation processes of increasing complexity for unmanned missions. The large distances between the spacecraft and the ground and the irreversibility of hardware failures are key features for the design of telematic applications used for space missions. This paper describes the mission control process on-board and on-ground. Examples taken from the operational experience with a nearEarth spacecraft and a deep-space scientific probe are presented and discussed. Copyright@ 20011FAC Keywords: Automation, Autonomous control, Control applications, Operability, Spacecraft autonomy, Space vehicles, Telecontrol, Telematics, Telemetry.
control of space missions.
I. INTRODUCTION Space missions involve sending a vehicle, manned or unmanned, away from the surface of the Earth, to distances and with velocities that allow it to follow trajectories basically only determined by the gravitational influence of the major solar system objects, the Sun, the Earth, the planets and their moons. The spacecraft or the set of spacecraft involved in a space mission are complemented on ground by the facilities used to establish the data links, remotely control the vehicle functions, collecting and processing the information transmitted by the spacecraft instruments. Telematics applications are required to integrate the space and ground segment of a space mission via data transmission in both directions in order to achieve the mission objectives. The aim of this paper is to give an overview of the approaches currently used for the
2. SPACE MISSIONS CATEGORIES AND TERMINOLOGY Since the beginning of the space era, with the launch of Sputnik 1 in Earth orbit in 1957, a large variety of space missions have been launched. These missions can be categorised through different criteria, such as duration, size, distance from Earth or from the Sun, objective, etc. From the point of view of telematics for mIssIon control the most significant categorisation is according to the presence of man in the control loop on-board the space vehicle or only on ground (manned or unmanned missions). Also a very important factor is the distance between the spacecraft and the ground control centre (deep-space or near-Earth missions).
129
2. J Space-Ground Links
2.3 Unmanned Missions
The data flow in both directions between a space vehicle and the ground is generally implemented via radio frequency links (typically S-, X-, Ko, Kabands). The groood to space direction is normally called telecommand link, or simply uplink. The direction from space to ground is called telemetry link, or downlink.
Unmanned spacecraft constitute the vast majority of space missions. Satellites are orbiting our planet to support telecomunication links, to provide invaluable data for meteorological or scientific observation of the Earth. Telescopes have been put into space to overcome the limitations of our abnosphere, opaque to entire bands of the electromagnetic spectrwn, and have opened our eyes to a new view of the sky and the Universe. Probes have been sent to the most remote corners of the Solar System, flying close to all known planets with the exception of Pluto (but in the next few years this gap will be filled), and in the vicinity of minor bodies like asteroids and comets. Vehicles have landed on the Moon, Mars, Venus, and a small asteroid called Eros. A probe will land on Titan, a moon of Saturn, in 2004, and missions are in preparation to be able to land on the surface of a comet nucleus.
On the spacecraft a main computer is in charge of decoding the signal received by the radi~frequency receiver and to execute and/or distribute the received digital telecommands to the final destination, which can be another computer, an internal software function, or a hardware switch. The same computer is nonnally in charge of collecting all data into a single digital telemetry stream, and to send it to the radio frequency transmitter for transmission to the groood. On groood a large parabolic antenna, of sizes from a few meters to a few tens of meters, is located in a groood station, in charge of receiving, amplifying and decoding the signals transmitted by the spacecraft, and sending them to the control centre, where all the control and monitoring computers are located, together with the mission control pa-sonnel. The control centre generates also the telecommands to be sent to the spacecraft via the ground station. Typically a single main control centre, plus a number of auxiliary control centres, exist for a specific space mission. On the other hand several ground stations are nonnally used, in sequence, in order to increase the period of contact with the spacecraft, which otherwise would be limited by the combination of Earth rotation and spacecraft trajectory. For some types of missions special satellites in Earth orbit are used as data relays, in order to increase the visibility periods without occupying the precious resource of the ground stations networks.
It is also thanks to telematics that all these achievements became possible. Unmanned space vehicles are completely dependent on the remote control from ground for all vital on-board functions, and of course for reception, processing and distribution the data which constitute their mission products. The main effect of not having a man onboard is the increasing need and use of robotics and autonomy functions. This is necessary for low Earth orbiters, which fly at altitudes of a few hoodred kilometers and go around the Earth in 90 minutes. These spacecraft would require a large network of ground stations or of data relay satellites in order to maintain a continuous contact with the ground. A relatively recent example of low Earth orbiter that experimented with advanced technologies and high levels of on-board autonomy was Eureca (Nellessen, 1994; Freundt, 1994). Another category of missions requiring on-board autonomy are the (deep-space) interplanetary probes: the distances reached by these spacecraft are so large that the radio signals carrying telemetry and telecommands have to travel for several tens of minutes at the speed of light before reaching the final destination. Typically, a Mars orbiter experiences one-way signal travel times to Earth from 4 to 20 minutes. Jupiter is already at about 40 to 50 minutes. Voyager 2, which is travelling since about 20 years towards the edges of our solar system, is now at a distance of almost 10 light-hours from Earth!
2.2 Manned Missions
The presence of astronauts on board a spacecraft constitutes a fundamental mctor for the definition of the architecture of the mission control applications and concepts. However, this does not remove the necessity of a the control loop via the ground control centre. In met, the safety aspects to be taken into account when flying a human being in space increase the need for a constant and extended monitoring of the spacecraft systems from ground. The presence of a man on-board the spacecraft shifts part of the telecommand traffic to the direct responsibility of the astronaut, who acts on switches and computers located in the spacecraft itself: The telemetry link remains, however, heavily loaded and in mct it tends to require larger bandwidths than for unmanned missions, and to include monitoring information also on the health status of the astronauts themselves. Transmission of video is normally also required.
3. TELEMETRY AND TELECOMMAND Although modern space missions include complex telematic networks both on ground (for muhi-user support, data distribution and distributed mission control) and on-board (intelligent users communicating with the central on-board computer via local area networks), the backbone of all telematic applications for a space mission is the
130
received telemetry data: the cost of communication lines between the ground station and the control centre increase exponentially with the line capacity. The solution generally adopted to reduce the cost is to utilise the station as a data buffer which is emptied during the non-coverage periods with the spacecraft by transmitting the accumulated data to the control centre over lower capacity lines. The spacecraft must separate on the downlink different categories of data, and in particular the data needed for the mission control process from the pure mission products (e.g. scientific measurements, Earth images, etc.). If the ground station is capable to identify the different types of received telemetry data it can store them locally and forward them to the control centre with different priorities. Alternatively direct user access to mission products at the ground station can be allowed by the mission control authorities; this allows to alleviate the load of the data link from the ground station to the control centre and to use it only for telemetry data used to close the control loops and to monitor the health status of the spacecraft.
telemetry and telecommand link between space and ground. This section deals with some of the most important aspects of these data links, their evolution and the currently adopted approaches and solutions.
3.1 Real-Time And OjJline Data Link Early space missions were based on direct, real-time telemetry and telecommand data flows. This implies extended use of ground stations and a heavy involvement of human resources for mission control. Slowly, with the evolution of technology and in particular with the increasing cost-awareness of all space projects, more and more space missions have been designed with the clear requirement of reducing ground contact to the minimwn necessary for the foreseen mission objectives. Reduction in the total amount of ground coverage has an immediate consequence on the mission design: either the amount of mission products (i.e. telemetry data) has to be reduced, or the telemetry link bit-rate during ground station contacts has to be increased. Normally the decision is to increase the telemetry bitrate and to provide the spacecraft with an on-board data storage capability. Data recorded during the non-coverage periods are multiplexed on the downlink during the ground station visibility period together with the telemetry data generated in realtime (store and forward approach). The same approach is normally taken for the telecommand link: all commands that have to be executed during the non-coverage period are uplinked to the spacecraft during the station pass and stored time-tagged in an on-board memory, from which they are fetched by the on-board computer at the correct execution time.
The telecommand link, which typically involves much lower bit-rates (of the order of a few Kbps), does not require to use the ground station as a data buffer. NormaUy, for mission safety reasons, a single source of telecommands is allowed, and this is the mission control centre. Even when different users can be allowed to control their instrwnents on-board the spacecraft via parallel telecommands flow, there are advantages of routing the complete command traffic to the station via a single mission control centre.
3.3 Fixed Format and Packet Telemetry The continuous bit stream forming the downlink is traditionally formatted into discrete consecutive units called ''telemetry frames". Each frame starts with a synchronisation word and ends with error detection and correction information. The description of coding standards and error handling methods typically used on the downlink goes beyond the scope of this paper. What is important, though, is to note the evolution of the use of telemetry frames, an evolution that has come with a significant delay with respect to the parallel evolution of the communications technologies and standards on ground.
Multiplexing of real-time and off-line datastreams (past data for the downlink, future data for the uplink) results in a major complication of the control software, which has to take into account this multidimensional data flow when closing the loop with telemetry data for verification of the correct execution of a specific telecommand. Telecommands can in fact be executed in real time or time-tagged, and the telemetry data containing verification information can be downlinked in real-time or stored and downlinked at a later time.
On traditional space missions, the telemetry frame contents is allocated through a fixed scheme to the various on-board data sources (e.g. subsystems, payloads). This is the approach called "fixed-frame telemetry", a very simple scheme, that has the disadvantage to waste a part of the telemetry bandwidth with unnecessary data. For example, a fixed space in the frame has to be reserved for temperature data measured on various locations onboard the spacecraft. These data change very slowly and a frequency of one sample every few minutes is normally more than enough for the purpose of
3.2 The Role o/Ground Stations An intermediate element that can complicate the data flow architecture and therefore the mission control process is the ground station. As indicated above, missions with short ground contact periods require high downlink bit-rates to achieve the required amount of mission product transmission to ground. On the other hand, the data links between ground stations and the control centre not always have the necessary capacity to aUow direct forwarding of the
131
900 million Km), a higher level uplink protocol has been implemented, that allows the uplink to continue to be accepted on-board even in case of discontinuities. At the end of the uplink session either no problem was detected and all received commands in the session are executed, or a report is generated that identifies all detected problems (i.e. missed telecommands) and transmitted to ground. Based on the received report the ground can re-uplink only the missing command frames without having to re-start the entire commanding session.
monitoring the spacecraft health status. On the other hand, with the fixed format frame a space for temperature data has to be reserved in each downlinked frame, at the expenses of other more valuable data (e.g. scientific measurements). This approach has become insufficient for spacecraft with increasing level of on-board complexity and autonomy. A more flexible solution, in use in the recent years in particular for scientific space missions, is the so-called "Packet Telemetry" approach. Each on-board data producer transmits its data within units, called packets, which are then put into the telemetry frames in order of generation, without any fixed scheme. This allows the on-board systems to use the downlink only when they have information to transmit, and autooomous functions to take context-specific decisions on when to generate and transmit specific types of telemetry data This scheme is more complex both for the on-board architecture and for the ground control systems, but necessary for missions having a very variable time profile of operations needs, resources availability, and payload complement
4. MISSION CONTROL PROCESS The major building blocks involved in the data flow for a typical space missioo are shown in figure l. All these elements are part of the mission control process and utilise various parts of the telemetry and telecommand data described in the previous section. In this section the mission control processes are described, with the help of examples and based of the scheme depicted in figure 1.
3.4 Uplink Protocols and Packet Telecommand Whilst 00 the telemetry side the emphasis of the techniques adopted is on flexibility and most efficient use of the bandwidth, on the telecommand side the most important aspect is guaranteeing a safe and complete reception m-board of the uplinked information. As the bandwidth available for commanding is normally largely unused, due to the relatively low information flow compared to the down link, the use of redtmdancy and repetition is quite extended in all telecommand standard approaches.
,------------- -----------------------------?~
.___s_~~<:~~ ________________ j
Fig. 1: Space Missioo Control Data Flow
An international standard for Packet telecommanding has also been defined and is used in most current and future missions of the European Space Agency and of other important space agencies. The most salient characteristic of this standard is the use of a safe frame uplink protocol that guarantees that all uplinked telecommand frames are received in the correct order and that no frames are missed in the sequence. If one frame is missed, all following frames are discarded. Information about the status of the on-board protocol machine is transmitted to the grotmd in the trailer of the telemetry frame, so that the protocol can be closed on-ground This is the safest possible approach but it is not the most efficient, in particular for missions that have inherent problems in closing the loop in real-time. For example, deep-space missions with a signal travel time of several minutes to a few hours cannot afford to wait for the protocol informatioo in telemetry for completing their commanding activity. In the case of Rosetta (SBrensen and Fern, 1998a), which will fly at Earth distances ofup to 6 Astronomical Units (about
4.1 On-board Data Flow Packetisation Modem spacecraft carry on-board several processors, each responsible of controlling a particular subsystem or payload instrument In general, though, there is always a single processor in charge of maintaining the interface with the ground via the radio-frequency subsystem. This tmit is what is called, using the traditional terminology, "on-board computer" in figure I. The data flow between the 011board computer and the single instruments or subsystems, over direct hardware links or one or more data buses, carries telemetry and telecommand packets, like the space-ground link, if the target unit is also miao-processor controUed and supports the same standard. This design solution has a number of advantages in terms of standardisatioo of development and simplicity of integration (Koenig et al., 1994). From the point of view of mission control if the instrument directly handles packets the overall data flow can be
132
utilised by some missions. It has to be restricted to very specific applications and needs high level control mechanisms to prevent localised misuse of mission resources.
seen as an end-to-end flow between the user centre on ground and the instrument on-board, where all intermediate elements only intervene on those types of packets that require intermediate processing in terms of monitoring and control (S/IJI"ensen and Ferri, 1994; 1998b). For example, a telemetry packet carrying scientific measurements (called Science Packet and identified as such by a specific field in the packet header), is never opened by the on-board computer nor by the mission control centre, and can flow directly to the relevant user centre without any intermediate processing. The on-board computer, the ground station and the control centre can identify it from the header, and treat it differently from other packets for what concerns intermediate storage and priority of transmission.
Independently of the level of autonomy of the spacecraft, it is responsibility of the control centre on ground initiate all tasks required for the execution of the mission, to ensure that the tasks are executed correctly on-board, and to monitor the overall health status of the spacecraft and its payload, taking corrective actions in case of anomalies. Typically each telecommand uplinked, whether for real-time or time-tagged delayed execution on-board, is verified by the ground control systems using information received from real-time or omine (on-board stored and forwarded) telemetry. When a support centre or a user centre sends to the control centre a request to carry out a specific activity on the spacecraft (e.g. changing the operation mode of a scientific instrument), the control centre is in charge of planning the activity, compatibly with the overall mission schedule and availability of resources, and to initiate and verify its successful execution. The support centre can then access via the control centre both the relevant instrument telemetry and also auxiliary information like the details of the execution verification process for the requested activity.
4.2 On-board Control loop Missions with a high level of on-board automation can close many control loops on-board This in general implies a reduction in the amount of data flowing in both directions on the space-ground link. For example, attitude control is a task normally performed on-board by a dedicated processor (or in some cases by the central on-board computer), using high frequency measurements from the spacecraft's attitude sensors, such as gyroscopes, sun sensors, etc. These high frequency measurements do not have, under normal conditions, to be downlinked to the ground: summary telemetry data, e.g. attitude angles and rates are sufficient for the ground monitoring. Of course the ground has to have access to the high frequency measurement in special cases, mainly for troubleshooting activities. Typically when an onboard autonomous process is controlled from ground the only data flow from the control centre is the instruction to con figure and to start the process. The received information on ground is also filtered, with summary information and typically success or faih.rre messages. The ground can decide to model the autonomous process in order to verify in real-time its behaviour using lower level telemetry information. However this is extremely complex and normally does not add value to the overall monitoring task. 4.3 On-ground Control Loop
4.4 Autonomy The use of automation on ground and the addition of autonomous processes on-board are rapidly increasing in the world of space missions, driven by the need to reduce costs and supported by modem information technology. As indicated above, some space missions can only be flown with an acceptable level of risk thanks to the implementation of onboard autonomous functions. Experience shows, however, that autonomy does not reduce, in fact it increases the complexity of the mission control process, and therefore it does not contribute to a reduction in the space mission operations cost (Wimmer et al., 1996). On the other hand more complex and sophisticated on-board autonomy architectures and fimctions are required for specific missions, like those devoted to interplanetary flight and solar system exploration. As explained above the long distances and the related signal travel time does not make it possible to close control loops in realtime with the ground. In addition, modem missions are pushed towards more and more unknown environments, for example in the case of planetary landers. These vehicles have to operate on terrains whose characteristics are largely unknown, and have to be able to adapt their movements and operations to the actual situation encountered, without relying on the help by mission control on Earth. The Rosetta mission, for example, (Verdant and Schwehm, 1998) carries a Lander which is designed to land on the surface of a comet's nucleus. The only known
Figure 1 schematically shows on ground, in addition to the grOlmd stations and the control centre, other building blocks called support centres and user centres. A support centre has a direct operational role in the mission control process. For example, for a scientific mission this centre can be the Science Operations Centre, in charge of coordinating all the inputs to the control centre for execution of payload operations. A user centre is specifically dedicated to the utilisation of the mission and can be, again in the case of a scientific mission, collecting, processing, archiving and distributing specific mission data. Figure 1 shows dotted lines connecting a user centre directly to the ground station. This approach is
133
multiplexing of data, always with the aim to optimise the bandwidth on one side, but also to ensure safety and reliability of the link on the other side. The need for cost reduction and the rapid development of informatics have shifted the emphasis towards automatioo and autonomy, which is being implemented and experienced in various fields of mission control.
characteristics of this object have been deduced from observations from Earth of the spectrum and luminosity of the material emitted when the comet approaches the SWl. Not even the size of the nucleus, estimated to be of the order of 600 m radius, will be known with precision Wltil the spacecraft will reach the comet in 2011 ! The implementation of automation on ground can, on the other hand, help in reducing mission operations cost. A strong push in this direction is being given by all major space agencies, with the aim to reduce the routine human intervention by having groWld systems autonomously executing all the routine mission control tasks. Whilst this is in principle relatively simple compared to normal industrial automation processes, it has to be taken into aCCOWlt that many space missions are Wlique, and last only a few years. This fact makes cost of producing and validating autonomous systems often larger than the related savings in mission operations cost. The correct approach to mission control automation is therefore a careful trade-off of development, test and validation cost against the expected savings in manpower. Also, a golden rule to be followed is the gradual implementation of autonomous functions, based on growing mission control experience during flight (Carneron et al., 1998; Ferri and Serensen, 1998; Ferri et al., 1999).
New mission control approaches and telematics concepts and applications will be required to master the ina-easing level of on-board autonomy for the future challenges of space enterprises, like the extensive robotic exploration of the solar system. Standardisatioo of protocols and applications is essential to afford future complex space missioos.
7. REFERENCES Cameron, G.E. and MH.Marshall (1998). Exploring the Practical Limits of Operations Autonomy. Proc. of the Fifth SpaceOps Symposium, Tokio, June 1998. Ferri, P. and E.M.S0rensen (1998) Automated Mission Operations for Rosetta, Proc. of the Fifth SpaceOps Symposium, Tokio, June 1998. Ferri, P., M.Warhaut and E.MSerensen (1999), Autonomous Procedures Execution: A Means of Reducing Rosetta Operations Cost, 3rd Symp. on Reducing Cost in Spacecraft Ground Systems and Operations, Tainan (/,aiwan), March 1999. FreWldt, E. (1994), The EURECA Remote Control Architecture. EURECA Technical Report, ESA WPP-69. European Space Agency, Paris 1994. Koenig, H., G.Urban and L.Scharringhausen (1994), The TMlTC Packet Concept: A benefit For The Payload. EURECA Technical Report, ESA WPP69. European Space Agency, Paris 1994. Neilessen, W. (1994), The EURECA Programme Objectives. EURECA Technical Report, ESA WPP-69. European Space Agency, Paris 1994. S9I"ensen, E.M and P.Ferri (1994). The Experience With EURECA Packet Telemetry And Telecommands, Proc. of the Third SpaceOps Symposium, Greenbelt (MA) 1994. Serensen, E.M. and P.Ferri (1998a), Use of Packet Telemetry and Telecommand for a Deep-Space Mission: The Rosetta Case, SpaceOps 98, Tokio (Japan), June 1998. Serensen, E.M. and P.Ferri (1998b), From Eureca to Rosetta: Operational Experience with Packet Telemetry and Telecommand Systems, First ESA Workshop on 1TC Systems, Noordwijk (NL), June 1998. Verdant, M and G.Schwehm (1998) The International Rosetta Mission, £SA Bulletin, 93, 39-50. Wimmer, W., P.Ferri and H.Huebner (1996). Onboard Autmomy, Eureca Experience and Requirements for Future Space Missions. Control Eng. Practice, Vol.4, 12,1715-1725.
5. FUTURE DEVELOPMENTS The ina-easing number and complexity of space missions requires on one side ever ina-easing capacity of the communication links; at the same time it raises the need for handling multi-satellite control for the same or for different missions in parallel Efforts are on-going in the direction of standardisation of space telematics, from communication protocols to applications at all levels. In particular the Consultive Committee for Space Data Systems (CCSDS) is defining standards for extending to space the concepts of data networks currently widely used on Earth. The aim is to move from the current typical point-to-point control of single spacecraft to a system that could allow spacecraft and even planetary landers to be included in a "Solar-System-Wide-Web".
6. CONCLUSIONS Space missions are depending on remote control for execution of all or most of the necessary functions. In addition, both on-board and on-ground networks of computers are involved in mission control and data generation, collection, distribution and processing. The space-ground link plays a central role in the overall mission control process, where different approaches have been developed for the transport and
134
TELEMATICS APPLICATIONS FOR THE REMOTE CONTROL OF SPACE MISSIONS
Paolo Ferri
European Space Agency / European Space Operations Centre RBosch Strasse 5, D-64293 Darmstadt, Germany
Abstract: Telematics plays a major role in space exploration, as all space missions involve remote control from ground. In addition, some control loops can be closed on-board, by human beings for manned missions, or by automation processes of increasing complexity for unmanned missions. The large distances between the spacecraft and the ground and the irreversibility of hardware failures are key features for the design of telematic applications used for space missions. This paper describes the mission control process on-board and on-ground. Examples taken from the operational experience with a nearEarth spacecraft and a deep-space scientific probe are presented and discussed. Copyright@ 20011FAC Keywords: Automation, Autonomous control, Control applications, Operability, Spacecraft autonomy, Space vehicles, Telecontrol, Telematics, Telemetry.
control of space missions.
I. INTRODUCTION Space missions involve sending a vehicle, manned or unmanned, away from the surface of the Earth, to distances and with velocities that allow it to follow trajectories basically only determined by the gravitational influence of the major solar system objects, the Sun, the Earth, the planets and their moons. The spacecraft or the set of spacecraft involved in a space mission are complemented on ground by the facilities used to establish the data links, remotely control the vehicle functions, collecting and processing the information transmitted by the spacecraft instruments. Telematics applications are required to integrate the space and ground segment of a space mission via data transmission in both directions in order to achieve the mission objectives. The aim of this paper is to give an overview of the approaches currently used for the
2. SPACE MISSIONS CATEGORIES AND TERMINOLOGY Since the beginning of the space era, with the launch of Sputnik 1 in Earth orbit in 1957, a large variety of space missions have been launched. These missions can be categorised through different criteria, such as duration, size, distance from Earth or from the Sun, objective, etc. From the point of view of telematics for mIssIon control the most significant categorisation is according to the presence of man in the control loop on-board the space vehicle or only on ground (manned or unmanned missions). Also a very important factor is the distance between the spacecraft and the ground control centre (deep-space or near-Earth missions).
129
2. J Space-Ground Links
2.3 Unmanned Missions
The data flow in both directions between a space vehicle and the ground is generally implemented via radio frequency links (typically S-, X-, Ko, Kabands). The groood to space direction is normally called telecommand link, or simply uplink. The direction from space to ground is called telemetry link, or downlink.
Unmanned spacecraft constitute the vast majority of space missions. Satellites are orbiting our planet to support telecomunication links, to provide invaluable data for meteorological or scientific observation of the Earth. Telescopes have been put into space to overcome the limitations of our abnosphere, opaque to entire bands of the electromagnetic spectrwn, and have opened our eyes to a new view of the sky and the Universe. Probes have been sent to the most remote corners of the Solar System, flying close to all known planets with the exception of Pluto (but in the next few years this gap will be filled), and in the vicinity of minor bodies like asteroids and comets. Vehicles have landed on the Moon, Mars, Venus, and a small asteroid called Eros. A probe will land on Titan, a moon of Saturn, in 2004, and missions are in preparation to be able to land on the surface of a comet nucleus.
On the spacecraft a main computer is in charge of decoding the signal received by the radi~frequency receiver and to execute and/or distribute the received digital telecommands to the final destination, which can be another computer, an internal software function, or a hardware switch. The same computer is nonnally in charge of collecting all data into a single digital telemetry stream, and to send it to the radio frequency transmitter for transmission to the groood. On groood a large parabolic antenna, of sizes from a few meters to a few tens of meters, is located in a groood station, in charge of receiving, amplifying and decoding the signals transmitted by the spacecraft, and sending them to the control centre, where all the control and monitoring computers are located, together with the mission control pa-sonnel. The control centre generates also the telecommands to be sent to the spacecraft via the ground station. Typically a single main control centre, plus a number of auxiliary control centres, exist for a specific space mission. On the other hand several ground stations are nonnally used, in sequence, in order to increase the period of contact with the spacecraft, which otherwise would be limited by the combination of Earth rotation and spacecraft trajectory. For some types of missions special satellites in Earth orbit are used as data relays, in order to increase the visibility periods without occupying the precious resource of the ground stations networks.
It is also thanks to telematics that all these achievements became possible. Unmanned space vehicles are completely dependent on the remote control from ground for all vital on-board functions, and of course for reception, processing and distribution the data which constitute their mission products. The main effect of not having a man onboard is the increasing need and use of robotics and autonomy functions. This is necessary for low Earth orbiters, which fly at altitudes of a few hoodred kilometers and go around the Earth in 90 minutes. These spacecraft would require a large network of ground stations or of data relay satellites in order to maintain a continuous contact with the ground. A relatively recent example of low Earth orbiter that experimented with advanced technologies and high levels of on-board autonomy was Eureca (Nellessen, 1994; Freundt, 1994). Another category of missions requiring on-board autonomy are the (deep-space) interplanetary probes: the distances reached by these spacecraft are so large that the radio signals carrying telemetry and telecommands have to travel for several tens of minutes at the speed of light before reaching the final destination. Typically, a Mars orbiter experiences one-way signal travel times to Earth from 4 to 20 minutes. Jupiter is already at about 40 to 50 minutes. Voyager 2, which is travelling since about 20 years towards the edges of our solar system, is now at a distance of almost 10 light-hours from Earth!
2.2 Manned Missions
The presence of astronauts on board a spacecraft constitutes a fundamental mctor for the definition of the architecture of the mission control applications and concepts. However, this does not remove the necessity of a the control loop via the ground control centre. In met, the safety aspects to be taken into account when flying a human being in space increase the need for a constant and extended monitoring of the spacecraft systems from ground. The presence of a man on-board the spacecraft shifts part of the telecommand traffic to the direct responsibility of the astronaut, who acts on switches and computers located in the spacecraft itself: The telemetry link remains, however, heavily loaded and in mct it tends to require larger bandwidths than for unmanned missions, and to include monitoring information also on the health status of the astronauts themselves. Transmission of video is normally also required.
3. TELEMETRY AND TELECOMMAND Although modern space missions include complex telematic networks both on ground (for muhi-user support, data distribution and distributed mission control) and on-board (intelligent users communicating with the central on-board computer via local area networks), the backbone of all telematic applications for a space mission is the
130
received telemetry data: the cost of communication lines between the ground station and the control centre increase exponentially with the line capacity. The solution generally adopted to reduce the cost is to utilise the station as a data buffer which is emptied during the non-coverage periods with the spacecraft by transmitting the accumulated data to the control centre over lower capacity lines. The spacecraft must separate on the downlink different categories of data, and in particular the data needed for the mission control process from the pure mission products (e.g. scientific measurements, Earth images, etc.). If the ground station is capable to identify the different types of received telemetry data it can store them locally and forward them to the control centre with different priorities. Alternatively direct user access to mission products at the ground station can be allowed by the mission control authorities; this allows to alleviate the load of the data link from the ground station to the control centre and to use it only for telemetry data used to close the control loops and to monitor the health status of the spacecraft.
telemetry and telecommand link between space and ground. This section deals with some of the most important aspects of these data links, their evolution and the currently adopted approaches and solutions.
3.1 Real-Time And OjJline Data Link Early space missions were based on direct, real-time telemetry and telecommand data flows. This implies extended use of ground stations and a heavy involvement of human resources for mission control. Slowly, with the evolution of technology and in particular with the increasing cost-awareness of all space projects, more and more space missions have been designed with the clear requirement of reducing ground contact to the minimwn necessary for the foreseen mission objectives. Reduction in the total amount of ground coverage has an immediate consequence on the mission design: either the amount of mission products (i.e. telemetry data) has to be reduced, or the telemetry link bit-rate during ground station contacts has to be increased. Normally the decision is to increase the telemetry bitrate and to provide the spacecraft with an on-board data storage capability. Data recorded during the non-coverage periods are multiplexed on the downlink during the ground station visibility period together with the telemetry data generated in realtime (store and forward approach). The same approach is normally taken for the telecommand link: all commands that have to be executed during the non-coverage period are uplinked to the spacecraft during the station pass and stored time-tagged in an on-board memory, from which they are fetched by the on-board computer at the correct execution time.
The telecommand link, which typically involves much lower bit-rates (of the order of a few Kbps), does not require to use the ground station as a data buffer. NormaUy, for mission safety reasons, a single source of telecommands is allowed, and this is the mission control centre. Even when different users can be allowed to control their instrwnents on-board the spacecraft via parallel telecommands flow, there are advantages of routing the complete command traffic to the station via a single mission control centre.
3.3 Fixed Format and Packet Telemetry The continuous bit stream forming the downlink is traditionally formatted into discrete consecutive units called ''telemetry frames". Each frame starts with a synchronisation word and ends with error detection and correction information. The description of coding standards and error handling methods typically used on the downlink goes beyond the scope of this paper. What is important, though, is to note the evolution of the use of telemetry frames, an evolution that has come with a significant delay with respect to the parallel evolution of the communications technologies and standards on ground.
Multiplexing of real-time and off-line datastreams (past data for the downlink, future data for the uplink) results in a major complication of the control software, which has to take into account this multidimensional data flow when closing the loop with telemetry data for verification of the correct execution of a specific telecommand. Telecommands can in fact be executed in real time or time-tagged, and the telemetry data containing verification information can be downlinked in real-time or stored and downlinked at a later time.
On traditional space missions, the telemetry frame contents is allocated through a fixed scheme to the various on-board data sources (e.g. subsystems, payloads). This is the approach called "fixed-frame telemetry", a very simple scheme, that has the disadvantage to waste a part of the telemetry bandwidth with unnecessary data. For example, a fixed space in the frame has to be reserved for temperature data measured on various locations onboard the spacecraft. These data change very slowly and a frequency of one sample every few minutes is normally more than enough for the purpose of
3.2 The Role o/Ground Stations An intermediate element that can complicate the data flow architecture and therefore the mission control process is the ground station. As indicated above, missions with short ground contact periods require high downlink bit-rates to achieve the required amount of mission product transmission to ground. On the other hand, the data links between ground stations and the control centre not always have the necessary capacity to aUow direct forwarding of the
131
900 million Km), a higher level uplink protocol has been implemented, that allows the uplink to continue to be accepted on-board even in case of discontinuities. At the end of the uplink session either no problem was detected and all received commands in the session are executed, or a report is generated that identifies all detected problems (i.e. missed telecommands) and transmitted to ground. Based on the received report the ground can re-uplink only the missing command frames without having to re-start the entire commanding session.
monitoring the spacecraft health status. On the other hand, with the fixed format frame a space for temperature data has to be reserved in each downlinked frame, at the expenses of other more valuable data (e.g. scientific measurements). This approach has become insufficient for spacecraft with increasing level of on-board complexity and autonomy. A more flexible solution, in use in the recent years in particular for scientific space missions, is the so-called "Packet Telemetry" approach. Each on-board data producer transmits its data within units, called packets, which are then put into the telemetry frames in order of generation, without any fixed scheme. This allows the on-board systems to use the downlink only when they have information to transmit, and autooomous functions to take context-specific decisions on when to generate and transmit specific types of telemetry data This scheme is more complex both for the on-board architecture and for the ground control systems, but necessary for missions having a very variable time profile of operations needs, resources availability, and payload complement
4. MISSION CONTROL PROCESS The major building blocks involved in the data flow for a typical space missioo are shown in figure l. All these elements are part of the mission control process and utilise various parts of the telemetry and telecommand data described in the previous section. In this section the mission control processes are described, with the help of examples and based of the scheme depicted in figure 1.
3.4 Uplink Protocols and Packet Telecommand Whilst 00 the telemetry side the emphasis of the techniques adopted is on flexibility and most efficient use of the bandwidth, on the telecommand side the most important aspect is guaranteeing a safe and complete reception m-board of the uplinked information. As the bandwidth available for commanding is normally largely unused, due to the relatively low information flow compared to the down link, the use of redtmdancy and repetition is quite extended in all telecommand standard approaches.
,------------- -----------------------------?~
.___s_~~<:~~ ________________ j
Fig. 1: Space Missioo Control Data Flow
An international standard for Packet telecommanding has also been defined and is used in most current and future missions of the European Space Agency and of other important space agencies. The most salient characteristic of this standard is the use of a safe frame uplink protocol that guarantees that all uplinked telecommand frames are received in the correct order and that no frames are missed in the sequence. If one frame is missed, all following frames are discarded. Information about the status of the on-board protocol machine is transmitted to the grotmd in the trailer of the telemetry frame, so that the protocol can be closed on-ground This is the safest possible approach but it is not the most efficient, in particular for missions that have inherent problems in closing the loop in real-time. For example, deep-space missions with a signal travel time of several minutes to a few hours cannot afford to wait for the protocol informatioo in telemetry for completing their commanding activity. In the case of Rosetta (SBrensen and Fern, 1998a), which will fly at Earth distances ofup to 6 Astronomical Units (about
4.1 On-board Data Flow Packetisation Modem spacecraft carry on-board several processors, each responsible of controlling a particular subsystem or payload instrument In general, though, there is always a single processor in charge of maintaining the interface with the ground via the radio-frequency subsystem. This tmit is what is called, using the traditional terminology, "on-board computer" in figure I. The data flow between the 011board computer and the single instruments or subsystems, over direct hardware links or one or more data buses, carries telemetry and telecommand packets, like the space-ground link, if the target unit is also miao-processor controUed and supports the same standard. This design solution has a number of advantages in terms of standardisatioo of development and simplicity of integration (Koenig et al., 1994). From the point of view of mission control if the instrument directly handles packets the overall data flow can be
132
utilised by some missions. It has to be restricted to very specific applications and needs high level control mechanisms to prevent localised misuse of mission resources.
seen as an end-to-end flow between the user centre on ground and the instrument on-board, where all intermediate elements only intervene on those types of packets that require intermediate processing in terms of monitoring and control (S/IJI"ensen and Ferri, 1994; 1998b). For example, a telemetry packet carrying scientific measurements (called Science Packet and identified as such by a specific field in the packet header), is never opened by the on-board computer nor by the mission control centre, and can flow directly to the relevant user centre without any intermediate processing. The on-board computer, the ground station and the control centre can identify it from the header, and treat it differently from other packets for what concerns intermediate storage and priority of transmission.
Independently of the level of autonomy of the spacecraft, it is responsibility of the control centre on ground initiate all tasks required for the execution of the mission, to ensure that the tasks are executed correctly on-board, and to monitor the overall health status of the spacecraft and its payload, taking corrective actions in case of anomalies. Typically each telecommand uplinked, whether for real-time or time-tagged delayed execution on-board, is verified by the ground control systems using information received from real-time or omine (on-board stored and forwarded) telemetry. When a support centre or a user centre sends to the control centre a request to carry out a specific activity on the spacecraft (e.g. changing the operation mode of a scientific instrument), the control centre is in charge of planning the activity, compatibly with the overall mission schedule and availability of resources, and to initiate and verify its successful execution. The support centre can then access via the control centre both the relevant instrument telemetry and also auxiliary information like the details of the execution verification process for the requested activity.
4.2 On-board Control loop Missions with a high level of on-board automation can close many control loops on-board This in general implies a reduction in the amount of data flowing in both directions on the space-ground link. For example, attitude control is a task normally performed on-board by a dedicated processor (or in some cases by the central on-board computer), using high frequency measurements from the spacecraft's attitude sensors, such as gyroscopes, sun sensors, etc. These high frequency measurements do not have, under normal conditions, to be downlinked to the ground: summary telemetry data, e.g. attitude angles and rates are sufficient for the ground monitoring. Of course the ground has to have access to the high frequency measurement in special cases, mainly for troubleshooting activities. Typically when an onboard autonomous process is controlled from ground the only data flow from the control centre is the instruction to con figure and to start the process. The received information on ground is also filtered, with summary information and typically success or faih.rre messages. The ground can decide to model the autonomous process in order to verify in real-time its behaviour using lower level telemetry information. However this is extremely complex and normally does not add value to the overall monitoring task. 4.3 On-ground Control Loop
4.4 Autonomy The use of automation on ground and the addition of autonomous processes on-board are rapidly increasing in the world of space missions, driven by the need to reduce costs and supported by modem information technology. As indicated above, some space missions can only be flown with an acceptable level of risk thanks to the implementation of onboard autonomous functions. Experience shows, however, that autonomy does not reduce, in fact it increases the complexity of the mission control process, and therefore it does not contribute to a reduction in the space mission operations cost (Wimmer et al., 1996). On the other hand more complex and sophisticated on-board autonomy architectures and fimctions are required for specific missions, like those devoted to interplanetary flight and solar system exploration. As explained above the long distances and the related signal travel time does not make it possible to close control loops in realtime with the ground. In addition, modem missions are pushed towards more and more unknown environments, for example in the case of planetary landers. These vehicles have to operate on terrains whose characteristics are largely unknown, and have to be able to adapt their movements and operations to the actual situation encountered, without relying on the help by mission control on Earth. The Rosetta mission, for example, (Verdant and Schwehm, 1998) carries a Lander which is designed to land on the surface of a comet's nucleus. The only known
Figure 1 schematically shows on ground, in addition to the grOlmd stations and the control centre, other building blocks called support centres and user centres. A support centre has a direct operational role in the mission control process. For example, for a scientific mission this centre can be the Science Operations Centre, in charge of coordinating all the inputs to the control centre for execution of payload operations. A user centre is specifically dedicated to the utilisation of the mission and can be, again in the case of a scientific mission, collecting, processing, archiving and distributing specific mission data. Figure 1 shows dotted lines connecting a user centre directly to the ground station. This approach is
133
multiplexing of data, always with the aim to optimise the bandwidth on one side, but also to ensure safety and reliability of the link on the other side. The need for cost reduction and the rapid development of informatics have shifted the emphasis towards automatioo and autonomy, which is being implemented and experienced in various fields of mission control.
characteristics of this object have been deduced from observations from Earth of the spectrum and luminosity of the material emitted when the comet approaches the SWl. Not even the size of the nucleus, estimated to be of the order of 600 m radius, will be known with precision Wltil the spacecraft will reach the comet in 2011 ! The implementation of automation on ground can, on the other hand, help in reducing mission operations cost. A strong push in this direction is being given by all major space agencies, with the aim to reduce the routine human intervention by having groWld systems autonomously executing all the routine mission control tasks. Whilst this is in principle relatively simple compared to normal industrial automation processes, it has to be taken into aCCOWlt that many space missions are Wlique, and last only a few years. This fact makes cost of producing and validating autonomous systems often larger than the related savings in mission operations cost. The correct approach to mission control automation is therefore a careful trade-off of development, test and validation cost against the expected savings in manpower. Also, a golden rule to be followed is the gradual implementation of autonomous functions, based on growing mission control experience during flight (Carneron et al., 1998; Ferri and Serensen, 1998; Ferri et al., 1999).
New mission control approaches and telematics concepts and applications will be required to master the ina-easing level of on-board autonomy for the future challenges of space enterprises, like the extensive robotic exploration of the solar system. Standardisatioo of protocols and applications is essential to afford future complex space missioos.
7. REFERENCES Cameron, G.E. and MH.Marshall (1998). Exploring the Practical Limits of Operations Autonomy. Proc. of the Fifth SpaceOps Symposium, Tokio, June 1998. Ferri, P. and E.M.S0rensen (1998) Automated Mission Operations for Rosetta, Proc. of the Fifth SpaceOps Symposium, Tokio, June 1998. Ferri, P., M.Warhaut and E.MSerensen (1999), Autonomous Procedures Execution: A Means of Reducing Rosetta Operations Cost, 3rd Symp. on Reducing Cost in Spacecraft Ground Systems and Operations, Tainan (/,aiwan), March 1999. FreWldt, E. (1994), The EURECA Remote Control Architecture. EURECA Technical Report, ESA WPP-69. European Space Agency, Paris 1994. Koenig, H., G.Urban and L.Scharringhausen (1994), The TMlTC Packet Concept: A benefit For The Payload. EURECA Technical Report, ESA WPP69. European Space Agency, Paris 1994. Neilessen, W. (1994), The EURECA Programme Objectives. EURECA Technical Report, ESA WPP-69. European Space Agency, Paris 1994. S9I"ensen, E.M and P.Ferri (1994). The Experience With EURECA Packet Telemetry And Telecommands, Proc. of the Third SpaceOps Symposium, Greenbelt (MA) 1994. Serensen, E.M. and P.Ferri (1998a), Use of Packet Telemetry and Telecommand for a Deep-Space Mission: The Rosetta Case, SpaceOps 98, Tokio (Japan), June 1998. Serensen, E.M. and P.Ferri (1998b), From Eureca to Rosetta: Operational Experience with Packet Telemetry and Telecommand Systems, First ESA Workshop on 1TC Systems, Noordwijk (NL), June 1998. Verdant, M and G.Schwehm (1998) The International Rosetta Mission, £SA Bulletin, 93, 39-50. Wimmer, W., P.Ferri and H.Huebner (1996). Onboard Autmomy, Eureca Experience and Requirements for Future Space Missions. Control Eng. Practice, Vol.4, 12,1715-1725.
5. FUTURE DEVELOPMENTS The ina-easing number and complexity of space missions requires on one side ever ina-easing capacity of the communication links; at the same time it raises the need for handling multi-satellite control for the same or for different missions in parallel Efforts are on-going in the direction of standardisation of space telematics, from communication protocols to applications at all levels. In particular the Consultive Committee for Space Data Systems (CCSDS) is defining standards for extending to space the concepts of data networks currently widely used on Earth. The aim is to move from the current typical point-to-point control of single spacecraft to a system that could allow spacecraft and even planetary landers to be included in a "Solar-System-Wide-Web".
6. CONCLUSIONS Space missions are depending on remote control for execution of all or most of the necessary functions. In addition, both on-board and on-ground networks of computers are involved in mission control and data generation, collection, distribution and processing. The space-ground link plays a central role in the overall mission control process, where different approaches have been developed for the transport and
134