* This article is an abbreviated version of the paper by C. Sollazzo et al. in Huygens: Science, Payload and Mission, ESA SP-1177, August 1997
Huygens is being carried as a passenger on NASA's Cassini Orbiter to Saturn, where it will be released to enter the atmosphere of Titan, the planet's largest moon. During the controlled descent phase, its instruments will execute a complex sequence of measurements to study the atmosphere's chemical and physical properties and, if it survives impact, Huygens will collect data on Titan's surface properties. Flight operations will be conducted from the Huygens Probe Operations Centre (HPOC) at ESOC. This article describes the ground-system infrastructure, procedures and constraints involved in operating Huygens over its 6.7-year mission lifetime.
Cassini will take 6.7 years to reach Saturn before Huygens is released into Titan's atmosphere and the Orbiter begins a four-year orbital tour of the planet, rings, satellites and magnetosphere. NASA's Jet Propulsion Laboratory (JPL) will control the Orbiter, whereas the Probe is ESOC's responsibility. The data exchange between Huygens and the HPOC - telecommands and telemetry - will be routed via the Cassini Mission Support Area (MSA) at JPL using NASA's Deep Space Network (DSN) facilities.
Cassini/Huygens mission operations will be carried out from these two centres, working in close liaison. Both spacecraft will be operated largely through pre-programmed, time-driven command sequences, either uplinked from the ground or activated by onboard software. After separating from Cassini, Huygens has no telecommand capability and so during the descent through Titan's atmosphere the operation of its scientific instruments is entirely automatic, driven by a combination of triggered and programmable schedules. To ensure mission success, all Probe systems are hot-redundant and their performances are checked out, up to Probe release, at regular intervals throughout the cruise to Saturn.
The Cassini/Huygens Ground System is designed to meet all the requirements of operating the combined mission under a 160 min round-trip light time (at Probe separation), with high reliability and within critical resource budgets, over a period of more than 10 years. It allows both flight control teams to manage the mission and to cope with its particular constraints and characteristics, especially those arising from the impossibility of having real-time interaction with the spacecraft and from the autonomous nature of many of the onboard systems.
Some 73 days after the Saturn orbit insertion burn of 1 July 2004, an Orbiter trajectory manoeuvre raises periapsis and targets the combined spacecraft for Titan impact. Huygens is released 22 days before the first Titan flyby on 27 November 2004. Two days later, the Orbiter performs a deflection manoeuvre to pass over the Probe's landing site. It then points its high-gain antenna at the predicted touchdown point to receive descent telemetry data and store it redundantly on two solid-state recorders. During its coast to Titan, Huygens is essentially dormant, with only a timer running. Twenty-four minutes before the predicted atmospheric entry, this timer triggers a sequence that applies power to the Probe subsystems and scientific instruments. The parachute-controlled descent through the atmosphere is initiated by a complex series of events driven by three redundant accelerometers, in a majority-voting configuration, monitoring deceleration as an indicator of Mach number. Pyrotechnic devices release the front shield and back cover, and a pilot parachute pulls out the main parachute. Subsequent events are triggered by a software timer, initiated at the moment of parachute release, T0. These events include establishing the radio relay, switching on further instruments and replacing the parachute with a smaller drogue to ensure that Huygens reaches the surface within 150 min. The descent time is constrained by the capacity of the Probe's batteries and by the changing geometry of the relay link as the Orbiter continues in its orbit about Saturn.
Critical functions such as pyrotechnics, which could endanger the mission if executed prematurely, are protected by an independent hardware timer that is initiated at a higher deceleration value a few seconds before T0. The instruments control their operations using information about time and predicted or measured altitude broadcast to them from the Probe command and data management subsystem. During checkouts, these operations are activated from a simulated T0, but in the absence of deceleration the arming sequence is not run.
Should Huygens survive the impact with the solid or liquid surface, it continues to transmit data until the batteries are exhausted and these data are recorded by the Orbiter until 30 min after the latest predicted touchdown. Later, the Orbiter is reoriented to transmit those recorded data to the Cassini Ground System. The Huygens Flight Control Team then transfers the data to the HPOC at ESOC. The Probe telemetry data is retained by the Orbiter until successful downlinking is confirmed.
Owing to the long propagation delays to be expected during most of the Cassini mission (up to 160 min round-trip light time), real-time monitoring and control looping - common for most near-Earth missions - are not feasible. A more suitable approach is that of uplinking a set of time-tagged commands every two months for subsystems, scientific payload and Huygens, covering all of the operational activities that must be performed during that time. These sets constitute the Sequence Programs, stored and executed by the Orbiter's Command and Data Subsystem (CDS).
To simplify the mission planning and sequence generation process, the mission is planned using 'operational modes' (i.e. power and data-rate resource envelopes applied to the operational states of the spacecraft subsystems and scientific instruments) and a limited number of 'unique' sequences. The spacecraft is always controlled through an operational mode, a unique sequence, or a pre-defined transition between operational modes.
All Probe activities are designed as 'unique' sequences. The Probe relay sequence is defined to be a 'critical' sequence in order to ensure that even an Orbiter fault condition does not prematurely terminate the relay sequence. The planning and generation of any Probe checkout, the release and the relay sequences is a coordinated effort between Cassini's uplink operations team at JPL and the Huygens operations team at ESOC. Figure 1 illustrates the process for scheduling, generating, validating and radiating sequencing programs to the Orbiter's control and data management system to control Probe activities.
Figure 1. Cassini uplink planning and generation process SASF: Spacecraft Activity Sequence File CDS: Command and Data Subsystem DSN: Deep Space Network
The long-range mission planning activities began about a year before launch. These consist of the analysis and coordination necessary to identify the major engineering, scientific and Probe activities necessary to achieve the mission plan, based on the latest trajectory data and related ground-support activities. Thereafter, the mission planning process for any given Probe activity begins about 8 weeks before the uplinking of the sequence containing that activity, and takes about 3 weeks to complete. After the mission plan has been updated to include the new activities, an activity plan is produced. During this process, which takes about 2 weeks, all conflicts are resolved and spacecraft activity sequence files are generated that specify the start and stop times of spacecraft activities.
During the sequence generation process, which lasts about seven working days, the activity plan serves as a basis for generating activity files at the command level. For a particular Probe activity, it includes Probe telecommands (which include instrument commands) submitted by Huygens operations personnel, and Orbiter commands submitted by Cassini operations personnel. The sequence integration and validation process, which lasts about 11 working days, integrates all the activity files that have been generated for a particular sequence.
Upon sequence validation and approval, the final Ground Command File is generated and queued at the station and radiated to the spacecraft. Upon uplink validation by the Orbiter CDS, the sequence programs are registered and sequence execution is allowed to commence.
The Cassini ground system performs the primary functions of mission planning and navigation, spacecraft command and control, spacecraft data acquisition, information processing and storage, and data distribution and archiving. These tasks are performed with the aid of a network of workstations interconnected via the Cassini local area networks (LANs). Figure 2 illustrates the interface connection between the facilities at ESOC and those at JPL. A Cassini Science Operations Planning Computer (SOPC) workstation is installed at ESOC as a gateway to the Cassini LANs.
Figure 2. The ESOC/JPL interface
During the cruise phase, a full Probe checkout about every six months verifies that no Probe failures or calibration changes have developed. The checkout data are analysed by the operations team and the Probe scientific calibration or simulated mission data are distributed to the instruments' Principal Investigators for their own processing and analysis. Any contingencies arising in a given checkout period are analysed between checkout periods and any reaction and corrective action is attempted during the next checkout. Recovery activities principally involve modifications to the Probe or instrument onboard software.
During the Saturn orbit phase (July to November 2004), all Probe subsystems and instruments are brought into their final configuration to perform the automatic descent sequence of operations, during a series of Probe checkout periods. Telecommanding is impossible once the Probe is released and from this moment on the Probe follows the automatic sequence of events programmed into the onboard software that drives its activities until the end of the mission.
The Probe Operations Centre
The functional breakdown of the HPOC is as follows (Fig. 3):
Figure 3. Overview of the Huygens Probe Operations Centre (HPOC) functionalities
The Huygens Monitoring and Control System (HMCS) provides the ground data processing facilities and interface support needed for proper execution of the Probe operations and the distribution of mission products to the external users involved.
The Science Operations and Planning Computer (SOPC) is the gateway for all operational data exchange between ESOC and JPL.
The Science Data Storage and Display is used by the Principal Investigators to analyse and display the mission scientific data collected during the Saturn orbit and descent phases.
The Mission Planning Support is responsible for defining, planning and validating any Probe operations needed.
There are also operational Interfaces with: JPL for the uplink and downlink functions, as well as for overall mission coordination; Principal Investigators' Home Institutes for scientific data distribution and instrument operations command inputs.
Also part of HPOC, and functionally closely related to the mission planning support, are the: Probe Simulator, which is the primary validation tool for operational procedures and onboard software design (it is also used for training the flight control team), and the Onboard Software Development Environment (SDE) needed to develop/maintain the onboard software and to validate new or modified software at subsystem level, before creating the relevant software update procedures, which in turn are validated at system level by using the Probe Simulator.
Power for the checkouts is provided by the Orbiter during the cruise and Saturn orbiting phases. During these phases, when the Probe is controllable from the ground by telecommand, carefully designed command sequences test the health of the Probe and instruments, and perform either a simulated descent sequence or special instrument calibrations.
The Probe is designed to perform its mission (the descent to Titan) automatically, with all activities driven by the onboard software based on a set of tables pre-defined for producing the 'best' mission output in the both the nominal and failure cases. The checkout is designed to demonstrate that the subsystems and instruments are completely healthy and able to support the mission.
Several months may elapse between the preparation of the command sequence for a given checkout and the actual reception and analysis of the telemetry data. As mentioned earlier, a finalised Probe command sequence for a given checkout period will usually be transmitted to JPL two months before its execution time. It may then take up to a week after the checkout execution before a suitable DSN pass can be used for downlinking the Probe-produced telemetry. All of the operational activities must be defined and properly planned with these constraints in mind: the planning and generation of any Probe checkout and of the final Probe release/data relay sequence is a coordinated effort between the Orbiter and Huygens operations teams.
The Probe checkout operations sequence can be modified by ESOC as required. It may be routine, but some anomalous Probe or instrument behaviours might have to be analysed and resolved. In principle, the functional sequence described below applies to all the checkout periods, including that for pre-separation, although here there are some additional activities.
The preparation activities define the checkout objectives and how to achieve them. This includes any special requests of operations for any instrument, as well as operational activities related to the investigation and solution of possible contingencies arising from onboard anomalies in the Probe, Probe Support Equipment (PSE, on the Orbiter) or instruments. To achieve the most efficient use of the checkout periods allocated to the Probe in the Cassini Mission Plan, the following inputs are needed at Tup-3 months (where Tup is the uplink time of the Cassini telecommand sequence):
Cassini Mission Planning: Contains the operations plan for the Orbiter around the time of the checkout, needed for coordination purposes with JPL.
Probe Activity Requests: Contain any requests for operations to be performed during the applicable checkout period.
Instrument Activity Requests: Contain any requests for special operations on the onboard instruments to be performed during the applicable checkout period.
The checkout operations sequence is illustrated in Figure 4:
Figure 4. The cruise-phase checkout activities
The Saturn orbit phase requires reaction times of the order of days, rather than the months of the cruise operations phase. Apart from two standard checkout periods, soon after the ring-plane crossing and before the Probe's release, some special tasks are performed.
Huygens has to rely on its onboard batteries for power after release. These are Li-SO2 primary cells, which must be depassivated before use by applying a controlled load for a few minutes to each. This is a critical activity because of its non-reversibility, and must be performed as close as possible to Probe separation in order to minimise the impact on battery capacity. The operation's success, on the other hand, has to be verified while the Probe is still attached to the Orbiter and commandable from the operations centre. The last Probe checkout before release would be too early, so a special operations sequence is foreseen for this activity about 8 days before release. One day before release, the three redundant coast timers are loaded with the value calculated to ensure that the Probe is woken up at the correct time, about 24 min before it reaches Titan's atmosphere. Before release, the content of these timers is checked on the ground to ensure their correct operation. A final 'go/no-go' decision to release the Probe is taken by ESOC, based on the successful verification of these final operations. In the event of a problem, the release can be aborted and postponed to the Orbiter's second Titan flyby. The coast phase starts at separation and ends at the entry into Titan's atmosphere at a nominal altitude of 1270 km; its maximum duration is 22 days.
The Huygens onboard software runs in a typical MIL-STD-1750A microprocessor environment and is configured in its operational form before launch. It is composed of two parts:
The onboard software has been designed to be reprogrammable. Indeed, in case of anomalies, software updates may be required as part of the contingency resolution. A software development facility is used for the maintenance of the Probe software and its validation at subsystem level. Its validation at system level is performed by means of the Probe simulator, which includes hardware emulators for the onboard processors. Once the validation process is satisfactorily concluded, the software update is archived and prepared for uplinking to Huygens. The final step is its onboard verification by analysis of the appropriate telemetry. Instrument software maintenance is handled by the relevant Principal Investigator. ESOC, however, is responsible for verifying that these updates do not affect the Probe at system level and, once this point is cleared, for uplinking them to the Probe for delivery to the relevant instrument.
After launch, any modifications to the software code are made by software patching. This involves loading a patch into EEPROM by telecommand. This stored patch is accessed only at the next power-on of the processor, when it is applied to the main RAM. Figure 5 illustrates the process and the hardware/ software relationships.
Figure 5. Probe system hardware/software interfaces CDMS: Probe Command and Data Management Subsystem CDS: Orbiter Command and Data Subsystem EXPs: Probe instruments POSW: Probe Onboard Software PSE: Probe Support Equipment RX: PSE Receiver SASW: Support Avionics Software SW: Instrument Software TC: Telecommand TM: Telemetry TX: Probe Transmitter
For the POSW and SASW, a new onboard memory image containing the patch is generated using the SDE, and passed to the HMCS Onboard Software Maintenance (OBSM) facility, where it is used to produce patch commands by comparison of the new image with a reference image of the onboard software. The HMCS provides utilities for the storage, management and configuration control of images, generation of patches and processing of memory dumps (including comparisons with stored images).
An equivalent process is used by the Principal Investigators when preparing software changes for their instruments, but the output is a set of instrument commands delivered to ESOC for incorporation into the next checkout sequence.