1 Introduction

PROBA2 is the second Project for Onboard Autonomy (PROBA) spacecraft, part of ESA’s in-orbit Technology Demonstration Programme. PROBA2 was launched on 2 November 2009 as a co-passenger to ESA’s Soil Moisture and Ocean Salinity (SMOS) spacecraft, and was injected in a Sun-synchronous, near-polar orbit at an altitude of approximately 725 km. It carries 17 technology demonstrators as well as four scientific experiments that address topics in solar science and space weather (see Santandrea et al. 2012).

The two primary scientific instruments, SWAP and LYRA, are controlled from the PROBA2 Science Operations Centre (P2SC) at the Royal Observatory of Belgium. The Large Yield Radiometer (LYRA: Hochedez et al. 2006; Dominique et al. 2012) is a small, compact solar ultraviolet (UV) radiometer, equipped with newly developed diamond detectors that are insensitive to visible light. LYRA monitors the variability of the solar irradiance in four ultraviolet pass bands, carefully selected for their relevance to aeronomy, space weather, and solar physics. The Sun Watcher using APS detectors and image Processing (SWAP: Berghmans et al. 2006; Seaton et al. 2012) is a successor of the Extreme-Ultraviolet Imaging Telescope (EIT: Delaboudinière et al. 1995) onboard SOHO. SWAP continues the systematic coronal mass ejection (CME) programme of the EIT instrument for systematic detection of space-weather related solar events. SWAP has an image cadence faster than two minutes and a FOV of 54 arcmin. SWAP and LYRA observe the Sun continuously, only interrupted by calibration or other dedicated scientific campaigns.

The Thermal Plasma Measurement Unit for Microsatellites (TPMU) and the Dual Segmented Langmuir Probe (DSLP) measure in-situ the environment of the Earth. The main objective of TPMU is to extend the series of similar plasma measurements carried out during the last two decades onboard the Magnetospheric and Ionospheric (MAGION) satellites. DSLP measures the density of the space plasma and its variations in the range of 102 to 106 particles cm−3, the electron temperature in the 500 – 3000 K range, and the satellite potential in the range of −5 V to 5 V. The instrument consists of two Langmuir probes. The plasma density and temperature are determined from the Langmuir probe current–voltage curve. Both instruments are contributions from and operated at the Academy of Science of the Czech Republic (Hercik et al. 2008).

After launch, the PROBA2 mission management was transferred from ESA’s Technical Directorate to ESA’s Science and Exploration Directorate, which is currently funding the mission. The PROBA2 Steering Group is responsible for all programmatic aspects of the mission. The Steering Group is made up of representatives from both ESA Directorates, representatives from the Belgian Science Policy Office (BELSPO), the Principal Investigators of the scientific instruments, a representative of the Royal Observatory, and a representative of the Mission Operations Centre (MOC).

The PROBA2 mission consists of the spacecraft, the reception stations, the Mission Operations Centre (MOC), the Science Operations Centre (P2SC), the Science Consortium of SWAP and LYRA (SCSL), and the final data archive at the European Space Astronomy Centre (ESAC), as depicted in Figure 1.

Figure 1
figure 1

The PROBA2 ground and flight segments.

Full size image

All science-planning aspects are discussed and decided by the Science and Technology Operations Working Group (STOWG). Representatives from all science instrument teams, industry, the MOC, and the two ESA Directorates form the STOWG, which convenes every six – eight weeks.

The P2SC is situated at the Royal Observatory of Belgium, Brussels, and co-located with the Solar Influences Data Analysis Centre (SIDC: Berghmans et al. 2002). Its responsibilities includes the science planning, the detailed instrument commanding, the production and delivery of scientific data to the scientific community, as well as the preparation of the long-term scientific archive. The long-term archive is hosted at ESAC alongside the SOHO archive (St. Cyr et al. 1995).

The MOC is located at the ESA Redu Station in Belgium. The MOC consolidates the science timelines with the required spacecraft and technology demonstrator timelines and uplinks them to the spacecraft using one of the S-band antennae at the Redu station. There are ten equally spread downlink passes per day supported by two S-band antennae located in Redu and one S-band antenna located in Svalbard. The telemetry downlink streams from all stations are processed at the MOC and forwarded to the P2SC.

The individual stages of commanding and data handling will be described in more detail in the following sections, followed by a summary of implementation issues, the finally selected hardware, and security aspects. Data distribution is discussed for SWAP and LYRA, followed by an overview of the Guest Investigator Programme. Finally, the lessons learned concerning implementation and operational aspects are given.

2 Instrument Commanding

2.1 Overview

The commanding of the scientific instruments is performed in three steps: the preparation of a long-term plan, the implementation of a weekly plan, and urgent short-term updates, if necessary.

A long-term plan covers six – eight weeks and is discussed and confirmed by the STOWG. All parties provide information on special scientific opportunities, joint observation plans with other satellites or observatories, instrument calibration campaigns, technology instrumentation campaigns, and spacecraft or on-ground maintenance activities. All information is collected and a conflict-free plan is agreed on during a working-group meeting. This long-term plan is the input for the Operations Calendar. All teams report on the execution and lessons learned from the previous planning period.

The short-term planning covers a full calendar week. An assigned person from the P2SC translates the information from the Operations Calendar into a commanding database, taking into account the latest environmental and planning information:

  • Periods when crossing the South Atlantic Anomaly (SAA), to avoid critical operations during this period.

  • Periods of spacecraft operations, again to avoid critical operations.

  • Periods of Earth occultations, to avoid acquiring useless data.

  • Periods of technology demonstrator activities that require dedicated scientific instrument modes.

A Planning Tool Interface (PTI) allows the entry and validation of the short-term plan using a web-based graphical user interface. The short-term plan is converted into a text-based file – the Instrument Operations Sheet (IOS) – containing the high-level commands for the SWAP and LYRA operations. The PTI supports the delivery of the IOS to the MOC and tracks the status of the high-level commands until they are successfully executed onboard. Once the weekly IOS of an instrument is uploaded, the operator can decide at any time to send a modified IOS via the MOC to the spacecraft. Onboard, the existing command buffer will be replaced by the newly uplinked commands. This option is rarely used, except in the following cases:

  • Unforeseen spacecraft events require an immediate adaptation of the already committed IOS.

  • Solar activity requires the update of commanding parameters.

  • Unforeseen resource conflicts require the update of commanding parameters.

2.2 Planning Tool Interface

The Planning Tool Interface (PTI) is the only interface for the P2SC to program the instruments. The interface provides a graphical display of planning information, including contents of the commanding and pass planning databases, SAA, and Large Angle Rotation (LAR) occurrences. A user has access to the tool via a secure channel over the Internet either as standard user or as operator. Only an operator can work on the commanding database, verify and send out an IOS to the MOC. Both types of user can re-load and visualise the commanding from the past. It is possible to create, edit, and modify sequences of instrument commands that can be saved in a commonly accessible workspace.

2.2.1 SWAP PTI

The PTI allows the programming of the SWAP imager in different observation and data modes:

  • Instrument ON/OFF/IMAGING/IDLE.

  • Onboard artefact removal, i.e. dead pixel removal and the setting of its threshold.

  • Rebinning and its parameters.

  • Recoding.

  • Bias settings.

  • Compression mode (i.e. OFF, JPEG, LZW) and its parameters.

  • Onboard priority number generation flag.

  • On-ground priority number setting.

  • Automatic CME detection mode.

Once SWAP is in imaging mode, continuous imaging is performed that is triggered by an acquisition command, allowing the control of

  • The sampling scheme, i.e. correlated double sampling or double sampling (De Groof et al. 2008).

  • The integration time.

  • The acquisition period or cadence.

  • The sub-windowing.

  • The gain settings.

  • The calibration LED activation.

  • The spacecraft off-pointing.

SWAP also allows commanding using a TABLE mode. A table contains the individual high-level commands as table elements. Once uploaded onboard, a part of the table can be selected by specifying the first and last table elements. All the commands between the first and last elements are then repeatedly executed in sequential order. The table may contain up to 100 elements, and it is thus large enough to hold a multitude of programming sequences. This scheme allows to upload several calibration tasks and nominal operation sequences once and then select within an IOS the command sequences to be executed. The table programming is fully supported in the PTI.

Some of the concepts are experimental in nature:

Onboard artefact removal:

Before the start of the image compression algorithm, image discontinuities (e.g. caused by cosmic rays or dead pixels) are removed by replacing corresponding pixel values by their nearest neighbours average. This approach reduces compression artefacts.

Recoding:

In case of image compression using the JPEG algorithm, the 12-bit pixel values are re-coded to 8-bit before compression (Nicula, Berghmans, and Hochedez 2005). A non-linear recoding algorithm is used to take advantage of the shot noise inherent in the measurement to reduce the data without sacrificing the dynamic range.

On-ground priority number settings:

The number of successfully downlinked images is dependent on a number of aspects. The overall downlink volume is determined by the amount of downlink passes, its durations, and the transfer rate between spacecraft and antenna. The onboard memory size determines the maximum number of images that can be stored between downlink passes. In the case that the onboard memory does not provide sufficient memory to store the next image acquisition, the onboard software determines the oldest image with the lowest priority setting, releases its memory that is then used to store the most recent image acquisition. The priority numbers must be programmed on-ground, e.g. by specifying – using the TABLE mechanism – a different priority number for each acquisition. If several images have to be deleted onboard due to lack of free memory, the deleted images will not be consecutive and thus the data gap is minimal. This mechanism ensures that in case of interesting solar events and the need to overwrite images onboard, the number of consecutive images lost is minimal. It also proved to be sufficient to guarantee the downlink of calibration or campaign data for PROBA2.

Onboard priority number flag:

Based on the same principle as the on-ground priority number settings, an automatic data-prioritisation process has been defined to set the priority numbers. This algorithm aims to identify potentially interesting solar events and transfer the associated data to the ground in higher priority. In-orbit tests and analysis showed that the algorithm did set the priority flag when passing the SAA. The implemented algorithm cannot distinguish between solar events and the increased noise level caused by the passage of the SAA.

Automatic CME detection:

In the automatic CME-detection mode, the onboard computer analyses each image to detect a CME and then re-points the spacecraft in the direction of the predicted CME movement. Post-launch analysis of the algorithm showed that the spacecraft pointing capabilities were not sufficient to guarantee the proper execution of the algorithm onboard, even though PROBA2 performs well inside of the originally designed margins for pointing stability. On-ground simulations using images of eruptions from SWAP are in progress and will be used to confirm whether an in-flight test of the algorithm is feasible.

Sampling Scheme:

The SWAP detector is an Active Pixel Sensor (APS) allowing several operation modes at the detector level. Two different modes of the detector can be programmed from within the PTI.

Calibration LED activity:

Between filter and detector, the SWAP instrument carries two LEDs for calibration purposes. The status of the LEDs can be commanded via IOS.

Spacecraft off-pointing:

The IOS allows to specify a spacecraft off-pointing of up to ± 3 degrees in two axes to map the corona far off the solar disk. The off-pointings can be commanded in an IOS without being in conflict with other subsystems. This feature is regularly used for scientific campaigns.

2.2.2 LYRA PTI

The LYRA radiometer can also be programmed in a high-level language, allowing the control of the three LYRA units and their detectors:

  • Instrument ON/OFF/WARM-UP/IDLE for the LYRA instrument.

  • Activation of one or two units out of the three LYRA has.

  • Cover control of each unit.

  • Voltage-to-frequency calibration period.

  • Integration time.

  • LED control.

2.3 P2SC/MOC Interface

The interface between the P2SC and the MOC is the IOS, which contains time-tagged, high-level instrument commands; one for each instrument. Each IOS is fully validated before it is transfered via a secure file transfer protocol (sFTP) to the MOC. The validation includes the syntax check of the individual commands, the range check of the given parameters as well as some context checks. The context checks guarantee that e.g. minimal periods between two adjacent commands are maintained. At the MOC, the IOS syntax is re-checked and each command is translated into low-level instrument commands that are then uplinked. For each of these steps, an incremental report is sent from the MOC to P2SC. The IOS related commands are uplinked to the satellite when received at least 15 minutes before the next planned uplink pass. Listing 1 demonstrates the IOS usage giving one example for the SWAP instrument, here explained line by line:

  1. 00

    Name of the instrument, either SWAP or LYRA.

  2. 01

    Unique identifier for each IOS.

  3. 02

    Creation date of this IOS file.

  4. 03

    Activation date of this IOS; onboard, all commands already existing and scheduled after this date are deleted.

  5. 04

    Start of a table configuration setting and prefixed with its activation date.

  6. 05

    First entry of the table configuration, defining:

    • Row number: 0.

    • Integration time: 10 ms.

    • Four corners of subwindow, in the example a full 1024×1024 window is specified.

    • Gain: 1.

    • Image cadence: 30 seconds.

    • Spacecraft off-pointings towards solar East – West: 0.0015; this corresponds to 11 arcmin.

    • Spacecraft off-pointing towards solar North – South: 0.0.

    • Usage of LED: on.

    • Priority number: 240.

  7. 06 – 07

    Second and third table entries, the first three entries define a calibration campaign with LEDs switched-on and the Sun outside the field-of-view.

  8. 08 – 10

    Fourth, fifth and sixth table entries defining a standard 100-second image cadence observation campaign with low priority numbers (0 is the lowest priority number).

  9. 11

    Start date of calibration campaign that loops continuously through the first, second and third tables entries until the next command starts.

  10. 12

    Start date of a standard observation campaign that loops continuously through the fourth, fifth, and sixth table entries; as there is no other command following, the observations continue until a new IOS with a new command is uploaded.

Listing 1

An example IOS file

figure a

3 PROBA2 Data Pipeline Architecture

3.1 Overview

All spacecraft communication frames received by the ground stations are processed at the MOC into instrument and housekeeping packets in the format of the Consultative Committee for Space Data Systems (CCSDS: CCSDS Secretariat 2000). For LYRA, these packets are transfered directly to the P2SC. The SWAP packets are reformatted into binary files such that one file contains all packets belonging to one image acquisition. All housekeeping packets are converted into physical values and stored in time-tagged ASCII files. The data coverage of the SWAP, LYRA, or housekeeping data is not necessarily covering the same time period, as the onboard downlink channels are independent of each other.

The data pipeline hosted at the P2SC is based on the Linux operating system and run as two virtual servers on VMware™. Once the incoming data files are received at a dropbox, a data flow concept processes all incoming files into intermediate and final products. The data flow is made of 31 software modules that are controlled and synchronised by a dedicated control module. All software modules are configurable via a human readable text configuration file. The modules are implemented in either Perl, PHP, Python, C, or IDL™.

3.2 Data Processing

Figure 2 shows the general structure of the P2SC science-data pipeline, sketching the most important software modules. The processing starts in three independent chains – one for LYRA, one for SWAP, and one housekeeping – that can be executed in parallel. All input files are pushed from the MOC onto the P2SC servers.

SWAP Telemetry Reformatter (SWTMR):

The SWTMR module starts up on the existence of a newly arrived binary SWAP input file. Each image is processed into an image file in FITS format containing the measured digital numbers of the detector as well as the decoded instrument housekeeping values contained in the input file. In addition, a thumbnail image in PNG format is created for quicklook support of the operators. The SWTMR is implemented in the C programming language.

LYRA Telemetry Reformatter (LYTMR):

The LYTMR module is triggered on the arrival of a new binary LYRA input file. All measurement samples as well as instrument housekeeping data are processed and ingested into a SQL database. The LYTMR module is implemented in the Python scripting language.

Auxiliary Data Processor (ADP):

The ADP module is triggered on the arrival of a new ASCII housekeeping input file. Most of the housekeeping parameters are extracted and ingested into a SQL database. The ADP module is implemented in the PHP scripting language.

SWAP Engineering Data Generator (SWEDG):

The SWEDG module is triggered by the successful completion of the SWAP Telemetry Processor or the Auxiliary Data Processor. The FITS files created by the SWAP Telemetry Processor are read and converted into new FITS files that contain, besides the raw image, all of auxiliary data that are needed in the further calibration chain. The SWEDG module is implemented in the C programming language.

LYRA Engineering Data Generator (LYEDG):

The LYEDG is triggered by the successful completion of the LYRA Telemetry Processor or the Auxiliary Data Processor module. A daily FITS file is created containing all measurement values as well as all necessary auxiliary data needed for the calibration process. As the data of several passes contribute to the final data spanning a one-day period, this FITS file is overwritten several times a day, triggered by the arrival of new instrument data or new housekeeping data. The individual time series of all of parameters are stored as binary extensions within each daily FITS file. The LYEDG is implemented in the Python scripting language.

SWAP Base Science Data Generator (SWBSDG):

The SWBSDG module is triggered by the successful completion of the SWAP Engineering Data Generator. Each FITS file is processed into a fully calibrated FITS file. The necessary calibration files (e.g. dark-current files and flat fields) are retrieved from the local file system using a file pattern matching selection method. The SWBSDG module is implemented in the IDL scripting language.

LYRA Base Science Data Generator (LYBSDG):

The LYBSDG module is triggered by the successful completion of the LYRA Engineering Data Generator. A daily, calibrated FITS file is created taking into account calibration files stored on the local file system of the P2SC. The LYBSDG module is implemented in the IDL scripting language.

SWAP Media Product Generator (SWMPG):

The SWMPG module is triggered by the successful completion of the SWAP Base Science Data Generator and produces, or updates, a daily movie file. The SWMPG module is implemented in the C programming language.

Cataloging tool (CLOG):

The metadata of the engineering and calibrated SWAP and LYRA products is inserted into databases to facilitate data mining. The CLOG module is implemented in the C programming language.

Data Consistency and Validation Checker (DCVC):

The DCVC module is triggered by the successful completion of the Auxiliary Data Processor and ensures the consistency of all available data sources within the P2SC. These include, e.g.,

  • The instrument planning consistency.

    The mode changes of an instrument are available in the P2SC and are compared against the planned instrument commands. As the instrument mode changes cannot be mapped one-to-one to the high-level IOS commands, for each IOS command a mode simulation is run and compared against the executed instrument mode changes onboard. Whenever a mode change is executed outside of an acceptance window, the DCVC throws a warning.

  • The instrument mode transition correctness.

  • The instrument mode transitions against known problems.

  • The housekeeping parameter range consistency.

  • The spacecraft parameters against instrument parameter consistency.

The DCVC module is implemented in the PHP scripting language.

Logging, Monitoring, and Triggering (LMAT):

All tools mentioned so far are orchestrated by a system backbone, named LMAT. Two configuration files contain the setup for the overall P2SC. The first configuration file defines the data flow based on the existence of files in dedicated directories. For each directory, a file pattern is specified and the name of the tool to run, if a pattern match is detected. The second configuration file defines the processing flow. For each tool in the P2SC, the configuration includes:

  • The maximum time the tool is expected to execute. After this time period, the LMAT stops the instance of the tool and flags the processing as unsuccessful.

  • The Internet protocol (IP) address of the server to run the tool on. This functionality allows the parallel execution of the data pipelines for SWAP and LYRA.

  • A priority number that allows the LMAT to start tools with higher priorities before others. Seven different priority numbers are in use to control all the tools of the pipeline.

  • The name of the tool to start after a successful completion.

All tools send information (i.e. errors, warnings, informational notes) to the LMAT. An LMAT graphical user interface provides an overview of the data pipeline and the execution of its tools to the operators. The LMAT module is implemented in the Perl scripting language.

Figure 2
figure 2

Architectural overview of the P2SC data processing.

Full size image

3.3 Data Pipeline and Instrument Health Monitoring

A graphical user interface, accessible through a secured network channel using any web browser, allows the monitoring of the data pipeline as well as the visualisation of all instrument and several spacecraft housekeeping parameters. The user interface, implemented in the PHP scripting language, lists all of the processes of the data pipeline and indicates their status: SCHEDULED, PROCESSING, PROCESSED OK, PROCESSED WITH WARNING, PROCESSED WITH ERROR. The tool allows the user to navigate quickly to all of the messages of an individual run of a module. ERRORS and WARNINGS can be dismissed either individually or all errors or warnings of a module run can be dismissed. Each error or warning is labelled by an identifier for which an explanatory text including possible resolutions and necessary activities is documented in an operational WIKI system. This functionality allows the operator to quickly get an overview of the data pipeline status and react adequately to errors. A basic visualisation tool allows the plotting against time of individual or several housekeeping parameters in one or a set of plots. The plots are produced on-the-fly and the operator can easily tailor the requested plots. As a result, the operator can judge the health and nominal operations of the instruments instantaneously. A LYRA quicklook viewer – also accessible via a web interface – allows the visualisation of data samples for arbitrary time periods. Movies of SWAP produced by the SWMPG allow quick evaluation of the imager operations. A set of command-line tools directly access the databases or FITS files, allowing the trend analysis of several parameters:

  • Temperature evolution of several thermistor values of the spacecraft and the instrument.

  • Dark current evolution over longer time periods.

  • Detector degradation over long time periods.

In addition to the Operational Calendar, all daily activities are logged in a log book, implemented on the operational WIKI system.

3.4 Implementation Issues

To allow flexibility in the small development team and to use the different advantages of a multitude of programming languages and supporting libraries, strict requirements towards the interfacing of the software modules towards the overall data-processing system were necessary. Each of the software modules must be capable of:

  • Being invoked from the command line as well as from the pipeline scheduler.

  • Reading in all settable parameters from a human readable, well-defined configuration file.

  • Sending defined start-up messages.

  • Sending warning and error messages using a defined syntax and globally defined identifiers.

  • Sending defined closing messages and exiting in a defined way.

To achieve this interface behaviour, the listed functionalities are implemented in Perl and compiled into a library that is then made available via an interface which is accessible by all programming languages employed.

The P2SC made use of a multitude of open-source software libraries, allowing a relatively short implementation phase.

3.5 Hardware

The development of the software modules was performed using several operating systems (i.e. Microsoft Windows™, Suse Linux™, Mac™ OS X). The final hardware selected is an off-the-shelf Linux workstation with a redundant disk system integrated into a 19-inch rack:

  • Two quad-core Intel™ 1.6 GHz processor boards.

  • 24×750 GByte RAID system.

  • Two Fiber Channel switches to connect the two processor boards to the RAID system.

Supplementary to the operating system, the usage of virtualisation allows the creation of isolated guest operating systems within a normal host operating system (Smith and Nair 2005). The usage of the VMware™ system within the P2SC allowed us to virtualise and isolate the data pipelines. This allowed us to physically disconnect servers that connect to the outside world (e.g. the interface P2SC/MOC or the public web server) from the P2SC internal servers thus increasing the security of the overall system. The virtualisation was also used to separate the development system from the operational system and allowed the quick building of test environments supporting distributed testing. The virtualisation can also be used to separate sporadically appearing tasks, e.g. the re-processing of data, from the rest of the operational system. It was felt very advantageous during the nominal mission to be able to fall back to an isolated system to re-process the full data archive without any interference and interaction to the archival system in use by the scientific community. The final usage of virtualisation covers the fall-back possibility onto a newly created system in case of hardware problems on the operational system.

3.6 Security

The PROBA2 Science Centre infrastructure is protected by the Observatory firewall. In standard configuration, only the publicly available data directories are visible and readable outside the firewall. A small set of port-to-port connections are allowed to support the data exchange between the Science Centre and the Mission Operations Centre, and the Science Centre and the long-term archive facilities at ESAC.

4 Data Distribution

All data are distributed via the PROBA2 home page . All distributed science data are in FITS format and the file structures are comparable to those used by SOHO (St. Cyr et al. 1995). All ancillary spacecraft data necessary to process the next calibration level are contained in the FITS files themselves.

4.1 SWAP Science and Quicklook Data

Table 1 lists all the data products available from SWAP (Seaton et al. 2012). Supplementary to these standard products, the SWAP calibration software and the calibration files that are necessary to convert engineering FITS files into calibrated FITS files are distributed via SolarSoft (SSW: Freeland and Handy 1998). The SWAP files are fully integrated into the SSW object-oriented programming system, which itself is freely available as a tree of the Interactive Data Language (IDL) programming environment. This allows any user to create customised calibrated images.

Table 1 SWAP distributed data products.
Full size table

4.2 LYRA Science and Quicklook Data

Due to the number of instrument units, their control, and the overall complexity of the instrument, several FITS files are produced (Dominique et al. 2012). Each of these contains the data of interest covering a full day. Table 2 gives a summary of these products.

Table 2 LYRA distributed data products.
Full size table

For the engineering-data level, seven different FITS files are available:

Standard Science Data (STD):

The standard FITS file contains all data samples of all four channels from UNIT 2 as a binary extension table.

Calibration Data (CAL):

All measurements of UNIT 2 obtained during calibration campaigns, typically these are LED calibration campaigns or dark-current measurements.

Meta–data (MET):

A daily FITS file with three tables, containing spacecraft housekeeping, instrument status information, and instrument-calibration voltage measurements. These tables are needed in the calibration process.

Backup Science Data (BST):

Same as STD, but for the backup unit.

Backup Calibration Data (BCA):

Same as CAL, but for the backup unit.

Rejected Data (REJ) and Backup Rejected Data (BRE):

Rejected data samples of standard and backup unit, respectively.

The data-type acronym is part of each file name.

All calibrated data from all channels are within one FITS file. The same is valid for the averaged data. LYRA reading routines are available via the SolarSoft tree of IDL.

4.3 Ancillary Data

Position, pointing, and time-related information is distributed via SPICE kernels (Acton 1996). These are made available from the PROBA2 WWW page , and are described in Table 3.

Table 3 PROBA2 distributed SPICE kernels.
Full size table

5 The Guest Investigator Programme

A Guest Investigator programme was initiated to support the PROBA2 science community. The programme foresees a yearly call for proposals – typically early Summer – with the selection of up to seven guest investigators, primarily Ph.D. students. A stay of several weeks at the P2SC is supported to shorten the time to understand the instrument, its commanding, and data analysis. An active participation in the science planning and operation is encouraged, especially when specific campaigns are requested to support the proposed data analysis.

The Guest Investigator programme of 2010 – 2011 received 16 proposals of which five proposals combined SWAP and LYRA data analysis, nine for SWAP, and two for LYRA. The proposer locations included China (one), Russia (four), India (three), Iran (one), and the US (one). The other proposers were from ESA member states: Austria, Belgium, France, Germany, the UK, and Greece. The six selected proposals covered the following science topics:

  • Understanding the solar UV and Lyman-α irradiance variability from LYRA observations.

  • Studying of the solar inner corona and searching for quasi-stationary coronal streams from active regions using SWAP off-disk observations.

  • Transients and their role in heating and acceleration.

  • Studying coronal holes and solar-wind velocity forecasts based on SWAP data analysis of the solar wind.

  • Cross-calibration and comparison of LYRA and SOLSTICE (Rottman, Woods, and Sparn 1993).

  • Reconstructing the solar variability from bandpass measurements.

The Guest Investigator programme of 2011 – 2012 received 15 proposals from India (two), Russia (three), US (two), Poland (one), and Croatia (two). The proposals from ESA members states received were from the UK (one), Ireland (two), Portugal (one), and Spain (one). In total, seven proposals were selected, covering:

  • Regularities of CME propagation in the new solar cycle.

  • Probing flare reconnection regions with LYRA and AIA.

  • Investigation of UV radiation of solar flares with LYRA.

  • The relationship between the on-disk “EIT wave” and its associated CME.

  • The study of the origin, evolution, and geo-effectiveness of narrow CMEs.

  • Blind deconvolution technique for accurately estimating the Point Spread Function of SWAP.

  • The long-term study of the solar EUV corona.

More information on the Guest Investigator programme can be found on the PROBA2 WWW page.

6 Lessons Learned from PROBA2

Several lessons were learned during the development and the first two years of operations of PROBA2:

High-level commanding language:

The high-level commanding language used at the P2SC is translated at the MOC into low-level instrument commands. These commands are then uplinked to the spacecraft. In case of uplink problems, the MOC reports these problems back to the P2SC often pointing to the low-level commands that were not uplinked. As the P2SC has no insight into these low-level commands, it cannot react correctly and is not able to translate the received information into the corresponding databases. For future science operations centres it is advised either not to translate the high-level commanding language at all and ensure that these high-level commands are executed onboard or that the science centre does the translation itself and has full visibility on all details.

Commanding life cycle:

Based on the previous point and also on the fact that housekeeping parameters are time-tagged at fixed intervals (not necessarily the same as used for the command tags), the P2SC is not able to unambiguously match the downlinked data to the uploaded instrument commands. As a result, the verification of the uplink stream is very complicated and not complete. The authors advise that any command or type of command is given a unique identifier that is bundled into the science-data packets whenever a corresponding command is executed. As an alternative, the identifier could be implemented for each instrument mode and would serve the same purpose.

Experimental instrument features:

Several experimental features were implemented to allow the optimisation of science data: onboard priority schemes, table programming, selectable compression, spacecraft off-pointing, etc. These features were implemented due to the fact that PROBA2 is a technology mission. The link from P2SC–MOC–spacecraft–MOC–P2SC was carefully analysed and optimised and finally implemented in each of these linked systems. Nearly all features were found to be very useful and are recommended to be considered for other missions.

Database usage to store highly sampled data:

LYRA and housekeeping data are sampled at high rate, e.g. 50 Hz for LYRA. The P2SC foresaw to store all samples in SQL databases. To achieve reasonable response times, major efforts on SQL database table optimisation as well as SQL table query optimisation had to be done. It is advised to estimate carefully during the design of a science segment the retrieval times assuming a maximum data and system load before agreeing on the selected storage architecture.

Virtualization:

The use of a virtual operating system was beneficial. The achieved redundancy was obtained by an increased processing time (e.g., a factor of two – three). None of the P2SC algorithms were processing intensive and the impact on the overall processing performance was minimal.

Usage of standard interfaces during implementation:

It was decided early in the design to allow different programming languages for the implementation. Team members were able to select a programming language that was either better suited for the implementation of the task or already providing powerful libraries. E.g. the SWAP calibration routines were implemented in IDL using the already existing SolarSoft library and allowing solar scientists – typically able to program in IDL – to redo the calibration steps themselves. This approach also allowed more flexibility to select team members for the implementation of the diversity of implementation tasks. To allow for this flexibility, a rigorous interface was defined for each of the programming languages used to guarantee the correct and standard execution of the error handling, the interfacing to the controlling dataflow mechanism, the calling interface, and the handling of configuration parameters. Especially for small projects with limited development resources, this is considered to be a valuable choice, if mutual interfaces have been precisely defined beforehand.

7 Conclusion

The implementation of the P2SC was carried out within 1.5 years. The data pipeline was verified very soon after the launch and already used with most functionality during the commissioning phase. Since then, the P2SC is operational and processes all data within 30 minutes of arrival. Interruptions are very rare and of short duration, typically less than four hours. The commanding tools are very flexible and the operator can react to solar activity within hours. The high-level commanding language allows the operator to discuss and program the instruments directly in cooperation with the scientists. The use of web-based tools allows the execution of the P2SC pipeline from any terminal in the world using secured access. The processed data products are available in near-real time and are freely accessible.

Within the context of the PROBA Guest Investigator programme, external solar physicists are regularly invited to join the P2SC for a period of a few weeks. They take part in the instrument planning and commanding, and the analysis of the resulting scientific data. The programme was found to be important to increase the visibility of a small science mission.

In closing, the implementation and operation of the PROBA2 Science Centre as a cooperation between the European Space Agency and the Royal Observatory of Belgium has been smooth and efficient, and it is considered as a success by all involved parties.