ADM-AEOLUS: an Innovative Operations Concept

Transcription

1 SpaceOps 2006 Conference AIAA ADM-AEOLUS: an Innovative Operations Concept P. Bargellini * and P. P. Emanuelli European Space Operations Centre (ESOC-ESA), Darmstadt, Germany S. Mejnertsen European Space Research and Technology Centre (ESTEC-ESA), Noordwijk, The Netherlands R. Gessner EADS-Astrium GmbH, Earth Observation, Navigation and Science, Friedrichshafen, Germany and D. Pecover ** EADS-Astrium Ltd, Earth Observation, Navigation and Science, Stevenage, UK The Atmospheric Dynamics Mission ADM-AEOLUS was selected in 1999 as the second Earth Explorer Core mission part of ESA s Living Planet Programme. Scheduled for launch in September 2008, AEOLUS will provide global observations of wind profiles paving the way for future meteorological satellites. Achievement of this last ambitious goal requires a substantial decrease in the operational effort associated to the routine mission phase. This in turn calls for implementation of an exceptionally high degree of on-board autonomy and definition of an innovative operational concept aimed at minimising ground intervention both in nominal and contingency situations. This paper will present the AEOLUS on-board autonomy requirements and resulting Failure Detection, Isolation and Recovery (FDIR) architecture. A novel mechanism for telecommand scheduling based on spacecraft orbit position, as provided by the on-board GPS receiver, will be introduced. The paper will then describe the associated Operational Concept allowing to reduce the number of ground station passes required to support the routine mission to one daily pass for real-time housekeeping telemetry reception, and a single telecommand upload session performed on a weekly basis. Finally, a summary of the overall ground segment will be provided and the AEOLUS Flight Operations Segment (FOS) specific facilities, based on the latest ESOC ground software infrastructure, presented. Nomenclature ADM = Atmospheric Dynamics Mission ALADIN = Atmospheric Laser Doppler Instrument AOCS = Attitude and Orbit Control System APF = Aeolus Processing Facility BRC = Basic Repeat Cycle CDMU = Command Data Management Unit ECMWF = European Centre for Medium-Range Weather Forecasts EEMCS = Earth Explorer Mission Control System FDIR = Failure Detection, Isolation and Recovery * ADM-AEOLUS Spacecraft Operations Manager, OPS-OEA, ESOC/ESA Robert Bosh Str Darmstadt. Head Earth Observation Operations Division, OPS-OE, ESOC/ESA Robert Bosh Str Darmstadt. System Software Engineer, TEC-SWS, ESTEC/ESA, Keplerlaan 1, 2200 AG Noordwijk. Operations Architect, Dpt AET22, Earth Observation Navigation and Science, EADS Astrium GmbH, Friedrichshafen. ** Operations Group Leader, ENS/AET21, EADS Astrium Ltd, Gunnels Wood Road, Stevenage, SG1 2AS, UK. 1 Copyright 2006 by European Space Agency. Published by the, Inc., with permission.

2 FOS = Flight Operations Segment GPS = Global Positioning System HLOS = Horizontal Line of Sight HKTM = Housekeeping Telemetry LEOP = Launch and Early Orbit phase LOS = Line of Sight MCS = Mission Control System MMPF = Mission Management and Planning Facility MTL = Mission Timeline NRT = Near Real Time NWP = Numerical Weather Prediction OBCP = On-Board Control Procedure OPS = On-Orbit Position Schedule PDS = Payload Data Segment RM = Reconfiguration Module s/c = spacecraft SIMSAT = Simulator Infrastructure for Modelling Satellites TTC = Telemetry, Telecommand and Control UV = Ultraviolet Introduction HE Atmospheric Dynamics Mission ADM-AEOLUS was selected in 1999 as the second Earth Explorer Core T mission part of ESA s Living Planet Programme. Scheduled for launch in September 2008, AEOLUS will provide global observations of wind profiles from space to improve the quality of weather forecasts, and to advance our understanding of atmospheric dynamics and climate processes. By demonstrating new laser technology, AEOLUS is seen as a pre-operational mission paving the way for future meteorological satellites to measure the Earth s wind. Although developed specifically for AEOLUS, the design of the satellite is based on a heritage of other ESA missions. The aim has been to build a spacecraft that is relatively simple to operate. This reduces the operating costs throughout its lifetime, and is also important for the future since several Aeolus-type satellites are later envisaged for operational use. AEOLUS Mission Overview After several decades of observations from space, direct measurements of the fully global, three-dimensional wind field are still lacking. There are deficiencies, including coverage and frequency of observations, in the current observing system. These deficiencies impede progress in both climate-related studies and operational weather forecasting while there is a clear requirement for a high-resolution observing system for atmospheric wind profiles. Experts need reliable instantaneous analyses and longer term climatologies of winds to improve their understanding of atmospheric dynamics, global atmospheric transport and the cycling of energy, water, aerosols, chemicals and other airborne materials. However, improvement in analysing global climate, its variability, predictability and change requires measurements of winds throughout the atmosphere. The AEOLUS mission aims to bridge this gap by acquiring global wind field measurements of the lower and middle atmosphere. The main mission objective is to provide observations of global wind profiles along the line-ofsight direction. The measurement data will allow achievement of the primary goals of AEOLUS: Provision of accurate wind profiles throughout the troposphere and lower stratosphere eliminating a major deficiency in the Global Observing System. Direct contribution to the study of the Earth s global energy budget. Provision of data for the study of the global atmospheric circulation and related features, such as precipitation systems, the El Niño and the Southern Oscillation phenomena and stratospheric/tropospheric exchange. Secondary mission objectives are related to provision of data sets for model variation and short-term windclimatologies allowing experts to: 2

3 Validate climate models through the use of high quality wind profiles from a global measurement system. Improve their understanding of atmospheric dynamics and the global atmospheric transport and cycling of energy, water, aerosols, chemicals and other airborne materials. Generate a number of derived products such as cloud top altitudes, aerosol properties and tropospheric height. AEOLUS measurements will be assimilated in numerical forecasting models, in order to enhance the quality of operational short- and medium-range predictions. Expected improvements are mainly due to the excellent horizontal and vertical sampling capabilities of the instrument, combined with a continuous availability of its data products within 3 hours after sensing. The data products will comprise, besides line-of-sight (LOS) Doppler shift data (Level 1A) and geolocated, horizontal line-of-sight (HLOS) wind observations (Level 1B), also information on aerosol/cloud distributions as well as various types of geometry and housekeeping parameters. The Level 2 set will include refined HLOS wind profile data and error information as required prior to assimilation in numerical weather prediction system (NWP), as well as various supplementary geophysical parameters. An essential element of the Aeolus mission will be a stable operational scenario throughout the entire exploitation phase with regard to measurement geometry and timelines and taking into account the various routine in-orbit calibration and characterisation tasks. A. Overall Spacecraft Configuration The AEOLUS spacecraft, designed for a nominal lifetime of 3 years (plus 3 months commissioning), has a total mass of about 1300 kg of which 450 kg are allocated to the payload. The spacecraft dimensions in launch (i.e. stowed) configuration are 4.6 m (height), 1.9 m (length), and 2.0 m (width). AEOLUS will fly in a Sun-synchronous dusk/dawn polar orbit characterised by: A nominal mean altitude at the equator of 396 km A mean inclination of 97 deg A Repeat Cycle of 109 orbits every 7 days Mean local time of Ascending Node set at 18:00 Figure 1 AEOLUS Configuration B. Payload Description The atmospheric wind will be measured by a single payload, the Atmospheric Laser Doppler Instrument (Aladin). Aladin has been designed to acquire height resolved laser backscatter signal in order to allow the retrieval of horizontal wind components in the observed target atmosphere throughout the troposphere up to the lower part of the stratosphere. The instrument is equipped with a lidar system operating in the UV (transmitter: diode pumped, tripled Nd:Yag laser, λ= 355 nm) in conjunction with a dual receiver system with high spectral resolution. It emits a short but powerful laser pulse toward the atmosphere, from which a small portion is scattered back by the air molecules and by cloud and aerosol particles. A 1.5 meter diameter telescope in Aladin collects this backscattered light and directs it to an optical receiver that measures the Doppler shift of the received signal. This Doppler shift is a direct measure of the difference velocity between the scatterers and the instrument in the direction of the laser pulse. If the measurement geometry and the residual satellite velocity are accurately known, the wind velocity in the projection of the line of sight to the Earth s surface can be derived. The altitude information is obtained by time of flight measurement between the outgoing laser pulse and the received backscatter signal. Through estimation of the Doppler induced frequency shifts in the backscattered signals, horizontal wind components will be detectable with an accuracy of 1 2 m/sec. When in nominal operation the instrument will send periodic sequences of pulsed radiation towards the atmosphere, at a nominal angle of 35 degrees with respect to nadir direction. A two-channel detection system will sense the Doppler shifted signals for both the Rayleigh (molecular) and the Mie (aerosol) components of the backscattered laser pulses, thus allowing retrieving the relative velocity between instrument and the observed atmospheric volume. By means of programmable time gating used within the detection system a vertical sampling in the range 250 m to 2 km can be achieved over a total acquisition height range from 0 km (surface) up to approx. 30 km. During nominal operation the attitude and orbit control system adjusts the platform s yaw angle such that the observed relative velocity of the LOS intersection point with the Earth surface is zero at any point along the orbit. 3

4 The instrument measurement cycle (or basic repeat cycle, BRC), consists of a sequence of laser pulses sent at a frequency of 100 Hz, over a duration of 7 sec, and is followed by a dead time of 21 sec. Given the resulting update period of 28 sec and the actual orbit and viewing geometry a horizontal smearing of approx. 50 km along-track is achieved whereas the horizontal spacing between subsequent wind observations is approx. 200 km. C. Platform Description The platform consists of a conventional box structure upon which Aladin is mounted. Two non-rotating solar array wings are located one forward and one aft of the platform with respect to the flight direction. The design includes a standard Power Control and Distribution Unit responsible for solar array power conditioning and distribution, complemented by a 64 Ah Li-Ion Battery providing the required energy storage capacity for LEOP and during eclipse phases. The 2450 W solar array output power provided at end of life allows to meet the mission power consumption profile. The data handling subsystem manages all onboard command and control functions as well as the attitude and orbit control by means of a high performance processor system. The AOCS subsystem features five specific modes: Standby Mode (SBM), Initial Acquisition Mode (IAM), Normal Mode (NM), Thruster Control Mode (TCM), and Safe Mode (SM). The on-board sensors suite includes two star trackers, a combined earth/sun sensor, two GPS receivers, four fiber optic gyroscopes, two magnetometers and a single coarse rate sensor (only used in SM). Four reaction wheels, three magnetorquers, and a mono propellant based reaction control system featuring ten 5N thrusters are used as actuators. AEOLUS utilises an S-band system for reception of telecommands at 2kbps, transmission of housekeeping telemetry at 8kbps, and the ranging activities necessary for ground based orbit determination. Nominal and emergency operations are supported via two quadrifilar helix antennas each with hemispherical coverage: one antenna is nadir pointing and is used for nominal communications with the TTC ground station. The other antenna zenith pointing guarantees an emergency link in case of attitude loss. The antennas are each connected to two S- Band transponders. Both receivers are permanently powered i.e. operated in hot redundancy. The transmitters are individually switchable on or off by telecommand and are operated in cold redundancy. Telemetry is transmitted simultaneously through both antennas. For measurement data storage and formatting, a mass memory sized to the mission needs and an appropriate formatter is implemented, which will provide the recorded data to a 10Mbps X-Band based down-link system featuring a single antenna located in the nadir face of the s/c. D. Ground Segment Description The Aeolus Ground Segment is in charge of the overall commanding and monitoring of the spacecraft as well as the acquisition, processing and dissemination of its observational data. The two primary components of the Ground Segment, the FOS and the PDS, comprise the following facilities and centres: The Flight Operation Segment featuring Prime Tracking, Telemetry and Command station, located in Kiruna/Sweden. Additional TTC stations (Svalbard and Troll) as required during the LEOP. Flight Operations Control Centre, including the Spacecraft Simulator, the Flight Dynamics System, and the Mission Control System (MCS), located at ESA-ESOC/Darmstadt Ground Communications Network The Payload Data Segment featuring The primary X-band acquisition station located in Svalbard/Norway The Aeolus Processing Facility located in Tromso/Norway, hosting the Level 1B / 2A instrument processor components, the short- and medium-term Archive / Inventory, the local monitoring, control and quality control functions, and the User Service and Dissemination Facility The ESA/ESRIN hosted PDS elements: the Aeolus Calibration and Monitoring Facility, the central Monitoring and Control Facility, and the Mission Management & Planning Facility The Long-Term Archiving and Multi-Mission User Service Facility, located at DLR/ Oberpfaffenhofen The Aeolus Level 2/Met product Processing Facility, hosted by the European Centre for Medium- Range Weather Forecasts in Reading, UK The FOS will be responsible for spacecraft commanding activities and acquisition of S-band telemetry during all mission phases. It provides the functionality required for generation and uplink of the routine platform and instrument command schedule, and the systematic archiving/analysis of the acquired housekeeping telemetry. Moreover, the FOS includes a Flight Dynamics System facility allowing orbit determination and prediction, and generation of attitude and orbit control telecommands. Other FOS functions include access to archived HKTM to authorized external users, e.g., industrial expert groups, analysis of ground station visibility segments required for 4

5 scheduling S-band and X-band communication intervals, and verification and uplink of on-board software patches. Besides performing the above routine tasks, the Mission Control Team running the FOS will be responsible for monitoring of the satellite s health status and implementing all necessary corrective / recovery actions in case of anomalies. The PDS will be in charge of reception of all recorded instrument measurement data, the systematic processing, archiving and dissemination of science data and of various planning and monitoring tasks. In particular, data transmitted via X-band will be downconverted, de-modulated and transferred to the APF, for systematic generation and archiving of Level 0 and Level 1 data products. Dissemination of Level 1 products will be executed in near-realtime (i.e. within three hours after sensing) or quasi real-time for relevant data subsets (i.e. within 30 minutes after sensing). The PDS will provide the measurement data to the Level 2/Met Processing Facility located at ECMWF, for assimilation in the operational forecast modeling and for generation of Level 2B/2C products. Other PDS functions include re-processing of data products, routine screening of all generated data and monitoring of quality parameters, provision of user services and long-term archiving. Finally, the PDS will perform top level planning of payload operation, including generation of instrument calibration settings, and periodic (i.e. weekly) submission of planning increments to the FOS. Mission Planning Facility MMPF External TT&C Network LEOP Support Plans Report TM/TC Plans Tracking data Flight Operations Control Centre (FOCC) ESOC AEOLUS S-band Commanding & HK TM Command and Data Acquisition Facility (CDFA) Kiruna TM/TC X-band visibility X-band HK Telemetry Figure 2 AEOLUS Ground Segment Primary X-band station X-band Recorded HK & Science TM X-band HK & Science data Secondary X-band stations PDS Monitor & Control AEOLUS FDIR and Autonomy The overall FDIR concept adopted in AEOLUS is driven by the objective to minimise ground intervention both during nominal operations and in failure scenarios. The FDIR approach is subject to the following top level requirements: The satellite shall survive a duration of at least 5 days after launch without ground contacts in nominal and one failure situations, without subsequent loss of mission. AEOLUS shall detect single faults, failures and errors. Where such events affect only instrument, the instrument may be switched to a non-operational state. Where such events affect platform operations the instrument may be switched to non-operational state, but the platform shall be reconfigured to continue its commanded mode. In exceptional cases it shall be permissible for the satellite to enter safe mode as a result of a single anomaly event. In Safe Mode H/W and S/W that is independent from H/W and S/W operated in nominal modes shall be used. Fault Detection, Isolation and Recovery shall be performed in a hierarchical manner with the aim of isolating and recovering faults at unit, subsystem or instrument level as far as possible. 5

6 During nominal operation including incidence of a single failure, there shall be no requirement for the control centre to send telecommands more often than once every 5 days. The AEOLUS software shall manage the mission timeline providing sufficient on-board storage to support the 7-day/109 orbits repeat cycle. Therefore the goal of the FDIR concept is to resume nominal operations where safe to do so and to safeguard the s/c in other cases. To maintain a simple implementation of the FDIR, nominal operations may be suspended during the FDIR action and only restarted once the FDIR actions are completed. In this case the missed scheduled operations are lost, i.e. there is no attempt by the onboard system to reschedule activities to recover the missed operations. The FDIR approaches used are: Fail operational approach: continue nominal operations (e.g. AOCS unit failures, heater / thermistor failures, X-band transmitter failures, etc). Fail safe approach: stop nominal operations (e.g. Aladin failures, AOCS functional failures, s/c undervoltage). This approach in turn has two major levels: fail safe of the instrument, resulting in autonomous switch down to an instrument safe state, but other s/c operations continue. fail safe of the s/c, in case of major anomalies that lead to a system reconfiguration (On-Board software restart, Processor reconfiguration or Safe Mode). The Aeolus FDIR concept is built around a top-down onboard control architecture. At the highest level hot redundant TTR boards within the CDMU contain Reconfiguration Modules which oversee the health and function of the CDMU and flight software by monitoring hardware alarm inputs and performing CDMU resets, reconfigurations and switches to Safe Mode as appropriate. At the next level the CDMU application software monitors and controls the spacecraft units by receiving and processing TM and sending telecommands. The software generates TM packets for transmission to ground and receives TC packets from ground either for immediate or timetagged execution. At the lowest level some units perform their own built-in health checks and report this through the TM to the CDMU software. For the platform functions, the FDIR needs to ensure that the s/c can safely recover from a failure, either by resuming operations autonomously or by switching to a mode of safe environmental conditions (note that AEOLUS is not designed to cope with double failures). For Aladin, the FDIR needs to ensure instrument safety by either stopping scheduled operations and switching the instrument into a safe and stable configuration until ground can intervene to localise the failure and restart operations or by switching Aladin off. The principal FDIR mechanisms are as follows: Failure detection functions (watchdog, software generated events and provided monitoring service) Failure identification/isolation functions (AOCS sensor cross-checks, autonomous recovery procedures triggered by events) Failure recovery functions (reconfiguration function, software provided event/action service, Safe Mode triggering, instrument internal switch-down) A. Redundancy Principle In order to avoid the loss of platform functions mandatory for the mission, a tailored redundancy concept is required. Thus, the redundancy concept of the platform has to be such that a single failure does not cause permanent loss of essential platform functions. Accordingly all units have to be independent of their redundant alternatives. This includes provisions to prevent malfunction or elimination of redundant units by a common cause. The redundancy implemented in AEOLUS is further an essential prerequisite to ensure the autonomy requirements and to achieve the required reliability. The redundancy principles can be characterised as follows: Hot redundancy is provided for vital S/C functions (as power generation, TC decoding, S-Band TC reception function) in order to provide redundant resources without the need for specific configuration commands. Cold redundancy (e.g. operation of one unit out of two available ones at a time) is provided for other HW units, e.g. Processor Module, AOCS units as GPS and star trackers Functional redundancy is provided for functions, which do not cause a significant degradation of the mission in case of their loss, e.g. thermal heaters. Cross-strapping is implemented as necessary to fulfill reliability requirements and to support operational backup configurations to be used in failure cases on subsystem level. The baseline design of the platform allows for the accommodation of a redundant instrument. Because the instrument interfaces are operated in cold redundancy, Aladin can make use of the interface which is active at a 6

7 time. Protection measures are implemented to avoid a blockage of instrument related platform functions in case of a single failure on Aladin side. B. Autonomy Concept The AEOLUS mission autonomy, which requires operations execution without ground intervention need over a period of up to five days (even in the case of single failures), relies on the overall redundancy architecture as described in the previous section and on appropriate implementation of autonomous FDIR functions on HW and SW level. Autonomous operation in AEOLUS can be distinguished between Autonomy in nominal operational cases (Nominal Autonomy) Autonomy in failure cases (Failure Case Autonomy) Nominal Autonomy describes basically the continuation of the Nominal Operations Sequence, i.e. when the instrument operates in a continuous manner. This operation is based on the continuation of activities according to a predefined list of the timetagged telecommands loaded in the mission timeline (MTL), being up-linked before execution and stored on-board, and continuation of X-Band down-link operations according to a predefined list of commands data being uploaded by ground in weekly intervals and stored in a separated on-board ops schedule (OPS). The five days autonomy requirement drives the dimensioning of the on-board telecommands queues (MTL and OPS). Failure Case Autonomy addresses the situation where an FDIR function (HW or SW) becomes active. This may lead to continuation of the nominal mission, interruption of nominal mission (MTL/OPS suspension) but no change of AOCS modes, reconfiguration on system level, or transition to Safe Mode. On-Board Command Scheduling Concept The AEOLUS mission calls for a high degree of autonomy with reduced ground centre intervention, so that the nominal operations will have to be executed according to a sequence of commands uploaded by the ground. In routine phase, this mission schedule will be loaded typically once every seven days. AEOLUS will support two schedule mechanisms: a Mission Timeline (MTL), where the activities are scheduled with respect to time, i.e. time-tagged. The MTL is mainly used for instrument and AOCS activities. an Orbit Position Schedule (OPS), where the activities are scheduled with respect to orbit position. The OPS is mainly used to schedule the X-band downlink activities. A. Mission Timeline (MTL) The basic reference for the mission activities is the on-board Mission Timeline (MTL), i.e. activities will be loaded by the ground in form of time-tagged telecommands and will be stored on-board in the MTL queue. The MTL will typically be used to manage routine platform servicing activities, AOCS commands to initiate slews and perform orbit manoeuvres, and execution of contingency recovery operations. Moreover, the MTL mechanism might be used to schedule the weekly instrument activities, which mainly consists of update and activation of the Aladin tables used to control the measurement parameters, and routine calibration execution. B. Ground Station pass time accuracy The accuracy of ground station passes start and end times must be within a time error of less than 10s to ensure correct reception of the recorded telemetry. However, Aeolus autonomy requirements state that there shall be no need to send commands to the spacecraft more frequently than once every five days. This means that, if the pass times were to be loaded by telecommand, then they must be calculated to an accuracy of better than ten seconds five days into the future. This is problematic because of the evolution of the s/c orbit under the influence of the external perturbations and orbit manoeuvre performance errors. The atmospheric density at the spacecraft altitude affects the drag force seen by the spacecraft. At the AEOLUS altitude, the drag is the most significant perturbing force. An incorrect estimation of the atmospheric density will lead to errors in the predicted position of the s/c directly translatable into errors in the times at which contact with the satellite can be made from the ground stations. The atmospheric density is affected by many factors not all of which are easily predictable. In particular the Solar Flux and the Geomagnetic Field have significant effects on the density and have strong random components. 7

8 An initial estimate of the difference in the absolute time of the ground station passes for a worst case atmospheric density fluctuation, leads to the violation of the ten second accuracy constraint after approximately 2.5 days. The alternative to telecommanding a list of contact times to the spacecraft is to calculate the contact times onboard. This novel concept, implemented in AEOLUS, is based on a set of on-board AOCS functions which calculate the spacecraft orbit position based on the on-board GPS receiver output. This method allows to command the satellite with a list of Arguments of Latitude against Orbit Number. Ground station contact is then assumed to start and finish when the AOCS calculates that the spacecraft is at the given values for the particular revolution. The difference in the Arguments of Latitude of the contact times can be translated into a time difference using the orbit period for the same worst case scenario described above. The accuracy is improved dramatically with the worst case error estimated to be approximately 4 seconds over a seven day period. This is not quite the complete error because this method now requires additionally that the ground stations update their knowledge of when the pass times will occur on a daily basis. This is done by automatic orbit determination and prediction performed by the Flight Dynamics System at the FOS. C. On-Orbit Position Scheduling (OPS) As described in the previous section, AEOLUS features a second reference for scheduling of on-board activities, the orbit position schedule (OPS). The OPS schedule allows to plan commands execution with respect to Orbit Number and angular offset from the ascending node (i.e. true anomaly + argument of perigee). The need for this arises from the required prediction accuracy for the switch-on of the X-Band transmitter at the correct location of the station. Since the orbit prediction will not be accurate enough to allow time-tagging for a complete week of operations, the down-link will be controlled by the in-orbit position maintained by the on-board orbit propagator on the basis of the on-board GPS measurements. A list of up-loaded orbits / positions will control the activation of the down-link including X-band transmitter switch ON/OFF, and resume / suspend of recorded data downlink. The following summarises the OPS scheduling concept applied in AEOLUS: The FOS loads X-band downlink information every 7 days. This schedule, covering a one week interval, contains the orbit numbers and the orbit phase information to start and stop the individual data downlink segments. The AOCS subsystem, based on GPS position measurements, raises an event upon ascending node crossing. The AOCS orbit propagator uses the ANX event to calculate when the OPS time for the downlink is elapsed (under consideration of the orbit number). Upon this elapse time the X-band subsystem is switched ON. The data downlink starts after a configurable delay from X-band switch-on to allow thermal stabilisation. The downlink stops at the predefined orbit phase. Finally, the X-band transmitter is switched OFF a certain time afterwards. D. On-Board Schedule Pick-Up Point Concept As described above, nominally AEOLUS will be operated using commands executed from the onboard schedules (MTL and OPS). In case of execution of an On-Board Control Procedure (OBCP) due to triggering of an on-board monitor there is a risk that the actions of the OBCP will be in conflict with the ground scheduled commands leading to a spacecraft configuration not compatible with the planned operations. In such a case continuation of the schedule could lead to unnecessary further triggering of monitors and resultant reconfigurations. To avoid this scenario, the following strategy has been developed: On initiation of an autonomous recovery action, the relevant OBCP will inhibit execution of commands to the involved subsystem from the onboard schedules, and suspend all monitors related to that subsystem. The OBCP will switch the affected subsystem into a defined post anomaly configuration that is frequently encountered during nominal operations. This is known as the Schedule Pick Up Configuration. On completion of the recovery actions, the subsystem continues to reject all commands addressed to it from the onboard schedules except for the Schedule Pick Up Command. At the relevant timetag, the Schedule Pick Up Command will be executed. If the subsystem is in the Schedule Pick Up Configuration the execution of subsystem commands from the onboard schedules will be re-enabled. If 8

9 the subsystem is not in the Schedule Pick Up Configuration the onboard schedule will remain inhibited until the next Schedule Pick Up Command when the checks will be repeated. The ground will routinely include a Schedule Pick Up Command in the onboard schedule just prior to the first command of the main subsystem functional operations initiated from that schedule. For example, in the case of the AOCS, a Schedule Pick Up Point would be included as the first command in the operational sequence used to perform an orbit manoeuvre or a slew to nadir pointing. This strategy of automatically picking up operations following an outage caused by an anomaly and associated reconfiguration can be applied to any routinely commanded subsystem. Although this approach cannot recover all lost scheduled operations it is highly appropriate to a low cost mission since it maintains high mission availability while avoiding the complexity and difficulty of testing arising with other methods. Note that to allow the proper implementation of this concept, it is necessary that all commands used in the onboard schedule address logical units rather than physical units. AEOLUS Operations Concept The main mission requirements behind the AEOLUS Operations Concept are listed below: Planning and execution of the nominal platform operations (AOCS routine telecommands upload, orbit manoeuvres, etc.). Monitoring of the satellite status and recovery from on-board contingencies. Planning and execution of instrument operations such to maximise the mission return. Management of the on-board storage such to minimise the loss of scientific data under nominal circumstances. Support of the interface with the MMPF for Aladin operations planning and for the exchange of ancillary data. A. Operations Concept Drivers The following list summarises the main characteristics of the Aeolus mission which determine the operations concept : Aeolus is designed such that during the routine phase can operate at least 120 hours without any ground intervention, even in the case of a single on-board failure. In order to minimise the costs of running routine operations, one single daily shift is planned on the FOS side on working days only by spacecraft operators. This introduces a constraint in the reaction to unpredicted events as well as in the execution of manual operations. It does not impose any constraint in the dumping of science data as this is going to be executed autonomously on-board as part of the planned operations using the OPS scheduling mechanism. Visibility of the spacecraft from the Kiruna station will be on average 10 minutes every revolution except the case of up to four consecutive orbits (once per day) during which the ground track does not cross the Kiruna visibility region. During routine operations the number of ground station passes dedicated to S-band telemetry acquisition and telecommand uplink will be minimised. In particular, a single ground station pass will be scheduled every day to acquire the S-band telemetry. Telecommands will be uplinked using two ground station passes once a week on a working day. The next subsections describe the Operations Concept by detailing two novel solutions implemented for the AEOLUS mission. B. Mission Planning Concept During the routine phase, all Aladin operations as well as all spacecraft operations which can be safely executed autonomously on-board will be planned sufficiently in advance and incorporated in a schedule increment i.e. an ordered list of commands covering one planning period to be uploaded on-board for future execution. The strategy adopted for Aeolus foresees a planning cycle based on calendar weeks. The instrument and spacecraft operations to be executed in week n are planned in week n-2 such to produce the relevant schedule increment at the latest by the Monday of week n-1. The planning inputs from MMPF consist of Aladin mode change requests, as well as modified instrument parameters and commandable tables. The applicable inputs are used in order to generate a summary schedule of activities to be performed, including the payload mode switching and the spacecraft operations which are strictly related to orbital events (such as the 9

10 dump of the on-board storage). As part of the summary schedule generation, it is possible to declare one or more visibility passes as unavailable (e.g. in the case of resource conflicts with other missions). The final output of the planning exercise is a schedule increment consisting of two On-Board Schedules containing commands to be loaded in the MTL or OPS queues, the Ground Schedule containing all release timetagged commands typically related to the pass operations automatically executed by the Mission Control System, and the Station Schedule containing a list of activities to be performed in order to configure the Kiruna station. During routine operation the On-Board Schedules covering the operations for one repeat cycle will be uplinked once a week using two consecutive Kiruna ground station passes. The uplink of the On-Board Schedule will be performed at least 12 hours prior to execution of the first command in the new schedule. C. Recorded Telemetry Handling Concept The mass memory used on AEOLUS features several independent circular buffers to store the housekeeping and scientific telemetry. It is fundamental to regularly dump these packet stores in order to ensure that no data is overwritten. The concept adopted for AEOLUS consists of a simple repetitive pattern of data dumps defined such that the planning of these activities can be achieved without maintaining a ground model of the amount of data stored on-board The dump of the on-board telemetry storage via X-band is autonomously started using the OPS schedule. This operation will be entirely managed by the on-board software by means of two mission specific PUS services allowing synchronising the dump activities with the spacecraft on-orbit position computed from the data provided by the GPS sensor. At weekly intervals, ground updates the on-board tables used by the software to correlate the X- band stations visibility pattern to the specific orbit number and s/c orbit position interval. Once the stored telemetry data have been transferred to the storage in the station via the X-band link, it is available for circulation and processing within the Payload Data Segment and for transmission to the FOS. The retrieval and processing of the playback HKTM by the FOCC will be performed automatically outside visibility periods. As described above, the downlink of recorded science data is performed in open loop. Therefore, in case a recorded orbit segment has not or only partially been received on ground (e.g. due to a X-band station unavailability), a second playback of the missed data segment will generally not be possible. This is deemed acceptable since the main objectives of the AEOLUS mission require availability of the data in NRT, for the measurements to be adequate for NWP forecasts. In case of lost recorded HKTM dump, a second attempt is possible within approx. 120 hours after sensing. To reduce the risk of missing HK telemetry, a re-dump of a complete 5-day period will be scheduled by default at appropriate intervals. Given the X-band downlink rate, a visibility period of approx. 180 seconds is required. AEOLUS Flight Operations Segment The AEOLUS Flight Operations Segment provides the capability to monitor and control the spacecraft and payload during all mission phases according to the Operations Concept outlined in the previous section. The FOS is part of the overall Aeolus ground segment and its main components are: Ground Station and Communications Network performing telemetry, telecommand and tracking operations within the S-band frequency. Telecommand will always be in the S-band, whilst telemetry will be in S-band for real time HKTM and X-band for recorded Science and HKTM data. The S-band ground station used throughout all mission phases will be the ESA Kiruna terminal (complemented by Svalbard and Troll during LEOP). Flight Operations Control Centre (FOCC) located at ESOC, including: The Mission Control System, to support, with both hardware and software Telecommand coding and transfer, HKTM data archiving and processing tasks essential for controlling the mission, as well as all FOCC external interfaces; The Mission Planning System (part of the Mission Control System), supporting command request handling and the planning and scheduling of spacecraft/payload operations; The Spacecraft Simulator, to support procedure validation, operator training and the simulation campaign before each major phase of the mission; The Flight Dynamics System, supporting all activities related to attitude and orbit determination and prediction, preparation of slew and orbit manoeuvres, spacecraft dynamics evaluation and navigation in general; 10

11 A General Purpose Communication Network, providing the services for exchanging data with any other external system during all mission phases. The following sections describe the main FOCC systems and facilities required in support of the AEOLUS mission, whereby use of existing facilities, both hardware and software, is made to the maximum extend possible. A. Mission Control System The AEOLUS Mission Control System (AMCS) will be used for the real-time telemetry processing, telemetry archiving, telecommand preparation and execution, on-board software maintenance, mission planning and additional support functionality (file transfer management, network interface system, etc). The AMCS consists of three distinct components: SCOS-2000, the EEMCS and the mission specific part. The SCOS-2000 infrastructure developed by ESOC is a software system covering all kernel functionalities in the area of spacecraft monitoring and control. In particular, it provides services for telemetry reception and processing, telecommanding uplink and verification, data archiving, display and retrieval. Other services, like remote telemetry and data disposition, are also available. SCOS-2000 is based on distributed client-server architecture and designed to support a generic spacecraft preferably responding to the ESA Packet Utilisation Standards. The generic implementation provided by SCOS-2000 must be customised and extended to support any specific aspect required by missions. The adoption of the same TM/TC data types, structures and services by several Earth Observation satellites with similar needs allows cross mission harmonisation in the MCS design, development and maintenance and the introduction of a so-called Earth Explorer Mission Control (EEMCS) kernel. In terms of requirements, the EEMCS is defined as delta with respect to SCOS-2000 infrastructure. Mission specific MCS functionalities designed and developed as part of the EEMCS, which are of generic nature across families of mission, are candidate to be feed back into SCOS-2000 infrastructure to be re-used by other SCOS-2000 based MCS. Additionally, functionalities responding to needs common within a mission family are grouped in the Earth Explorer Requirements Kernel as a second layer on top of SCOS-2000 infrastructure. The AEOLUS mission specific functionality is then built on top of the EE Kernel. As shown in Figure 3, the concept of software reuse is based on the reuse of the ESA MCS infrastructure, SCOS-2000, and on the reuse of common functionalities that have been identified within the Earth Explorer family of missions, represented by the EEMCS kernel. I/F I/F (c) Cryosat Goce Aeolus (d) (d) (d) (b) EEMCS (e) (a) SCOS Figure 3 - Functionality Layering within a Mission Family From the above figure, it is possible to identify: A) SCOS-2000 functionalities fully reusable by any EE mission B) EEMCS functionalities common to across EE missions C) Mission-specific functionalities D) Functionalities implemented by specific missions, but candidate for repatriation in the EEMCS E) Functionalities implemented in the EEMCS, but candidate for repatriation in SCOS The main advantages of introducing the EEMCS kernel are represented by an increased flexibility and fast reaction in satisfying mission needs, a considerable decrease of the mission MCS development time and cost, and the provision of a unique starting point for new MCS developments. The various AMCS components are not static, but have their own dynamics. In particular, SCOS-2000 evolves following the overall ESOC MCS infrastructure plan. The EEMCS evolves, on one hand, following the evolution of SCOS-2000 and, on the other, incorporating new generic family functionalities from the mission specific part. Figure 4 provides a simplified graphical representation of the evolutionary concept behind the AMCS. The AEOLUS Mission Control System will be the first mission specific development to make use of the latest SCOS-2000 version 5.0, featuring multi-mission and multi-domain capabilities. Moreover, the AMCS will also integrate a number of new infrastructure tools currently under development, namely: 11

12 The Network Interface System (NIS), replacing the NCTRS in providing the interface between the MCS and the ground station. It will feature a number of improvement and new functionalities, among which the possibility to automate the TC/TM links management. The EGOS Data Dissemination System (EDDS), providing controlled access to mission data (housekeeping telemetry, telecommand history, ancillary files) to external users. This tool will replace three subsystems currently used to provide the above functionality, i.e. WebRM, TDRS and GDDS. The Mission Automation System (MAS): providing the functionality to manage the automatic scheduling of relevant SCOS-2000 interfaces, i.e. automatic telemetry verification, telecommand release, etc. SCOS-2000 V3.1 V4.0 V5.0 V6.0 time EEMCS V5 V5.1 V6 V7 V8 V9 CRYOSAT(CGMCS5) CRYOSAT(CGMCS5.1) GOCE(CGMCS6) AEOLUS (AMCS1) AEOLUS (AMCS2) AEOLUS (AMCS3) Figure 4 AMCS Evolution Concept B. Spacecraft Simulator Even with unlimited access to the satellite it is not possible to undertake all desirable tests. Some test cases, which assume malfunction of, or would apply physical damage to the spacecraft can be realistically assessed only with the help of a simulator. In order to utilise the spacecraft most efficiently, and to minimise any risk to it, the operational software and procedures will be thoroughly validated beforehand by using the software simulator. The Satellite simulator software developed by ESOC models the satellite subsystems, the satellite environment and the relevant parts of the ground segment. It executes in real-time and represents the s/c behaviour as it is observed at the FOCC. The simulator accepts all valid commands and executes those commands, which would be accepted by the real spacecraft in the same mode. It models failure cases and non-nominal modes of operation; failures will be propagated from one subsystem to the other. Payload modelling is limited to reflect realistic housekeeping telemetry and response to telecommands; however, scientific behaviour and pertinent TM/TC is not modelled. The CDMU processor (ERC32) is emulated. This allows the direct use of actual on-board software, increasing realism of the model and flexibility in adapting the simulator to late changes in the spacecraft software. The satellite simulator makes use of ESOC s SIMSAT infrastructure, a software package aimed at providing run-time support for simulation models, and a set of pre-defined generic models that simulator developers may use to reduce development effort. The run-time Kernel is the heart of SIMSAT and is responsible for scheduling models, event logging, user commanding, visualisation of model data and the saving/restoring of the simulation state-vector. SIMSAT features a set of generic models and libraries, including a TM/TC model (SIMPACK), an accurate position and orbit determination model (PEM), an electrical network modelling mode (SENSE), and the ERC32 processor emulator. These models and libraries were originally developed for SIMSAT-VMS. Recently, they have been ported to run with SIMSAT under Windows and Linux operating systems. The AEOLUS simulator will be the first mission specific development to make use of the latest SIMSAT version running on the Linux operating system. C. Flight Dynamics System In support to the AEOLUS mission, the Flight Dynamics Division at ESOC will provide the relevant operational services during all mission phases in the following areas: Orbit determination, prediction and control AOCS monitoring, including sensors calibration and fuel bookeeping AOCS command generation 12

13 Point positioning data delivered by the on-board GPS receiver will be the primary source of tracking data used for orbit determination during the routine operations phase of the mission. Range and doppler data acquired from the ground stations will be used as a back-up method for orbit determination when GPS data is not available. This concept allows to reduce the number of daily ground station passes required to determine the spacecraft orbit. The flight dynamics software and tools will be developed making extensive re-use of the operational facilities used by other Earth Observation missions (ERS/ENVISAT/CryoSat/GOCE). In particular, orbit determination, prediction and control aspects will be supported by the NAPEOS (Navigation Package for Earth Observation Satellites) software package. Conclusion The AEOLUS spacecraft design features a high degree of on-board autonomy and a multi-layer FDIR architecture allowing to simplify the operational requirements and thus achieve a significant decrease of the routine mission costs. An innovative Operational Concept has been defined based on the use of a novel mechanism to schedule the telecommand execution using the spacecraft orbit position, as provided by the on-board GPS receiver. This allows to reduce the number of ground station passes required to support the routine mission to a single pass dedicated to realtime housekeeping telemetry reception scheduled daily, and one telecommand upload session performed on a weekly basis. The AEOLUS Flight Operations Segment (FOS) is being assembled making extensive re-use of elements developed in the context of previous Earth Observation ground segments. Moreover, AEOLUS will be the first mission to incorporate some of the latest ESOC infrastructure developments in particular in the area of mission control system, with the integration of the multi-mission SCOS-2000 version 5, and the spacecraft simulator with the use of the SIMSAT Linux version. References 1 Mardle, N., Earth Observation Integrated Family Of Missions Concept : A Cost Effective Approach To Mission Operations Preparation And Execution, SpaceOps 2006 (to be published). 2 Reggestad, V., Earth Explorer Mission Control System: a new child is born (Aeolus) SpaceOps 2006 (to be published). 13