The Projects for Onboard Autonomy (PROBA2) Science Centre: Sun Watcher Using APS Detectors and Image Processing (SWAP) and Large-Yield Radiometer (LYRA) Science Operations and Data Products
- First Online:
- Cite this article as:
- Zender, J., Berghmans, D., Bloomfield, D.S. et al. Sol Phys (2013) 286: 93. doi:10.1007/s11207-012-0033-6
- 741 Downloads
The PROBA2 Science Centre (P2SC) is a small-scale science operations centre supporting the Sun observation instruments onboard PROBA2: the EUV imager Sun Watcher using APS detectors and image Processing (SWAP) and Large-Yield Radiometer (LYRA). PROBA2 is one of ESA’s small, low-cost Projects for Onboard Autonomy (PROBA) and part of ESA’s In-Orbit Technology Demonstration Programme. The P2SC is hosted at the Royal Observatory of Belgium, co-located with both Principal Investigator teams. The P2SC tasks cover science planning, instrument commanding, instrument monitoring, data processing, support of outreach activities, and distribution of science data products. PROBA missions aim for a high degree of autonomy at mission and system level, including the science operations centre. The autonomy and flexibility of the P2SC is reached by a set of web-based interfaces allowing the operators as well as the instrument teams to monitor quasi-continuously the status of the operations, allowing a quick reaction to solar events. In addition, several new concepts are implemented at instrument, spacecraft, and ground-segment levels allowing a high degree of flexibility in the operations of the instruments. This article explains the key concepts of the P2SC, emphasising the automation and the flexibility achieved in the commanding as well as the data-processing chain.
KeywordsPROBA2SWAPLYRAScience operationsInstrument and data management
Auxiliary Data Processor
Active Pixel Sensor
Belgian Science Policy Office
LYRA Backup Calibration FITS File
LYRA Backup Science FITS File
LYRA Calibrated FITS File
Coronal Mass Ejection
Consultative Committee for Space Data Systems
Data Consistency and Validation Checker
Dual Segmented Langmuir Probe
Extreme-ultraviolet Imaging Telescope
European Space Astronomy Centre
Flexible Image Transport System
Interactive Data Language
Instrument Operations Sheet
Joint Photographic Expert Group
Large Angle Rotation
LYRA Base Science Data Generator
LYRA Engineering Data Generator
Large Yield Radiometer
LYRA Telemetry Processor
Magnetospheric and Ionospheric Satellites
LYRA Meta-data FITS File
Mission Operations Centre
PROBA2 Science Centre
Portable Network Graphics
Projects for Onboard Autonomy
Planning Tool Interface
LYRA Rejected FITS File
South Atlantic Anomaly
Science Consortium of SWAP and LYRA
Solar Influence Data Centre
Soil Moisture and Ocean Salinity
Structured Query Language
LYRA Standard FITS File
Science and Technology Working Group
Sun Watcher using APS detectors and image Processing
SWAP Base Science Data Generator
SWAP Engineering Data Generator
SWAP Media Product Generator
SWAP Telemetry Reformatter
Solar and Heliospheric Observatory
Thermal and Plasma Measurement Unit
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).
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
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.
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.
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
Onboard artefact removal, i.e. dead pixel removal and the setting of its threshold.
Rebinning and its parameters.
Compression mode (i.e.OFF, JPEG, LZW) and its parameters.
Onboard priority number generation flag.
On-ground priority number setting.
Automatic CME detection mode.
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 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.
- 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.
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
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.
2.3 P2SC/MOC Interface
Name of the instrument, either SWAP or LYRA.
Unique identifier for each IOS.
Creation date of this IOS file.
Activation date of this IOS; onboard, all commands already existing and scheduled after this date are deleted.
Start of a table configuration setting and prefixed with its activation date.
- 05First 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.
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.
- 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.
- 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).
Start date of calibration campaign that loops continuously through the first, second and third tables entries until the next command starts.
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.
3 PROBA2 Data Pipeline Architecture
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
- 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 DCVC module is implemented in the PHP scripting language.
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.
- 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.
3.3 Data Pipeline and Instrument Health Monitoring
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
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.
The P2SC made use of a multitude of open-source software libraries, allowing a relatively short implementation phase.
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.
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
SWAP distributed data products.
Measured digital numbers
Dark-current, flat-field, and gain corrected
Thumbnails of raw data
Daily movie file of calibrated data
Average intensity over full field-of-view
4.2 LYRA Science and Quicklook Data
LYRA distributed data products.
Daily Fits files
Dark-current and degradation corrected
Calibrated, one-minute averaged data
Images containing daily, one-minute averaged, calibrated data
Images containing three days, one-minute averaged, calibrated data
- 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.
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
PROBA2 distributed SPICE kernels.
Instrument FOV orientation and shape
NAIF leap-second kernel
NAIF planetary-constants kernel
GPS time to UTC time conversion
Spacecraft position information
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.
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.
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
- 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.
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.
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.
PROBA2 was implemented by ESA’s Technical Directorate under the General Support Technology Programme (GSTP). In 2006, the Science Progamme Committee (SPC) adapted PROBA2/SWAP and LYRA as part of ESA’s National Led Mission programme for a nominal duration two years after launch, thus funding the flight, ground, and science segments of the mission as part of ESA’s mandatory science programme, lead by ESA’s Science and Robotic Exploration Directorate. In 2010, the SPC granted a mission extension until December 2012. SWAP is a project of the Centre Spatial de Liège and the Royal Observatory of Belgium funded by the Belgian Federal Science Policy Office (BELSPO). LYRA is a project of the Centre Spatial de Liège, the Physikalisch-Meteorologisches Observatorium Davos and the Royal Observatory of Belgium funded by the Belgian Federal Science Policy Office (BELSPO), and by the Swiss Bundesamt für Bildung und Wissenschaft. The P2SC development was funded by BELSPO and implemented under PRODEX Contract 90209, LYRA Preparation and Exploitation, and under PRODEX Contract 90193, SWAP Preparation to Exploitation.
This article is distributed under the terms of the Creative Commons Attribution License which permits any use, distribution, and reproduction in any medium, provided the original author(s) and the source are credited.