Institut national de recherche scientifique français Univerité Pierre et Marie Curie Université Paris Diderot - Paris 7

PLATO N-DPU Flight Software

Monday 15 January 2024, by Philippe Plasson

The N-DPU flight software is the software that drives the 24 normal cameras on the PLATO payload. This software implements photometry algorithms that reduce the flow of data produced by calculating directly on board the flux of stars that will be used by the ground segment to construct light curves and detect exoplanets. This software was designed and produced by LESIA’s flight software team.

 The PLATO mission

PLATO (“PLAnetary Transits and Oscillations of stars”) is a M-class mission of the European Space Agency foreseen to be launched at the end of 2026. PLATO aims to characterize exoplanetary systems by detecting planetary transits and conducting asteroseismology of their parent stars.

The PLATO payload concept is based on a multi-camera approach, involving a set of 24 normal instruments monitoring stars fainter than mV=8, plus a smaller set of 2 fast instruments observing extremely bright stars with magnitudes brighter than mV=8.

The PLATO satellite and its 26 cameras
The PLATO satellite and its 26 cameras


 PLATO on-board Data Processing System

The PLATO Data Processing System, called DPS, is the sub-system of PLATO payload module in charge of the on-board data processing (data acquisition, data reduction, data compression, monitoring, etc.). The DPS is a set of several on-board computer boards connected via a SpaceWire network. The DPS architecture is composed of:

  • 12 Normal Data Processing Units (N-DPU) embedding a GR712RC dual-core LEON3FT processor.
  • two Fast Data processing Units (F-DPU).
  • two Instrument Control Units (ICU) working in cold redundancy.
The PLATO on-board data processing system
The PLATO on-board data processing system


The N-DPU and F-DPU are in charge of processing respectively the data of two normal cameras for each N-DPU and the data of one fast camera for each F-DPU. The ICU are in charge of managing the payload, the communication with the Service Module (SVM) and the compression of scientific data before transmitting them as telemetry to the SVM.

 N-DPU boards and MEU

The N-DPU board is made up of the following parts:

  • 1 dual core LEON3FT GR712RC SoC clocked at 50MHz
  • 1 SDRAM of 256 MiB (64 M x (32b+16b))
  • 4 SpaceWire interfaces


The MEU device is an integrated box made up of:

  • 6 N-DPU (Normal Data Processing Units)
  • 2 PSU (Power Supply Units, main and redundant)
  • 2 SpaceWire router units

The MEU H/W is provided by Spain (IAA-CSIC / IAC / Thales Alenia Space).

Block diagram of the MEU
Block diagram of the MEU


MEU box
MEU box


 PLATO N-DPU flight software overview

The N-DPU Flight Software (or N-DPU ASW for N-DPU Application Software) is the embedded software deployed in each of the 12 N-DPU boards. The N-DPU ASW has been specified, designed, implemented, validated and qualified by LESIA.

Each N-DPU ASW manages two cameras (four 21-million pixel detectors per camera) and collects science and housekeeping data from their front-end electronics (N-FEE).

During the Observation mode, each N-DPU unit is receiving window segments of observed stars from both N-FEE as inputs. The window segments are transferred every 6.25 seconds through a single SpaceWire link per N-FEE. The window segments are then reconstructed back using a lookup table into windows and are processed by the N-DPU ASW.

In the observation mode, the N-DPU ASW role is to produce 6x6-pixel square-shaped windows (i.e. raw star windows called "imagettes" not transformed on-board) for 21% of the incoming stars (out of 132350 stars per camera) and photometry products using binary mask algorithms for 79% of them. The photometry products are made up of star fluxes and centers of brightness of stars. The N-DPU ASW computes also the offset, background, smearing and performs outlier detection to improve the SNR of the products. The N-DPU ASW calculates light fluxes and centers of brightness every 25 seconds. These photometry products are then averaged over 50 and 600 seconds (samples of 2 and 24 measurements respectively). The averaged photometry is then sent to the ICU. The other 21% stars (27500) of each N-cameras are directly transmitted to the ICU.

PLATO N-DPU ASW processing pipeline
PLATO N-DPU ASW processing pipeline


The definition of all the scientific algorithms is made by the PLATO DPA-WG.

In support of the "Observation" mode, the N-DPU flight software features a mode that automatically calculates the positioning of the star windows on the CCDs, based on the telescopes’ attitude and the star catalog giving their positions in the barycentric celestial reference system (BCRS).

In addition to the science services, the N-DPU ASW offers services dedicated to the calibration activities: full-image acquisition service and window acquisition service.

Last but not least, the N-DPU ASW implements the standard PUS services for checking the telecommand packets, managing the production of housekeeping reports and event reports, handling the time, accessing to the N-DPU and N-FEE memories (load, dump and check), managing and monitoring the on-board parameters, etc.

 N-DPU flight software architecture

A multi-core architecture built with GERICOS framework

The architecture of the N-DPU ASW is built according to an Asymmetric Multi-Processing approach (AMP) using the GERICOS framework running on top of the RTEMS 4.8 real-time kernel (Edisoft version). The GERICOS (GEneRIC Onboard Software) platform is a generic LESIA platform for the development of software for space payloads.

With the GERICOS::CORE framework, a real-time application is built as a set of active objects (called "tasks"), each active object having its own message queue and its own computational thread. Each Thread processes incoming messages one by one by executing the function associated with the message.

The support of the AMP architecture in the GERICOS framework relies on the intrinsic features of the active object paradigm of the GERICOS::CORE layer. With this paradigm, two objects communicate via marshalled messages. Each object is split in an implementation object (which implements the services offered by the object) and in a stub object which is responsible for the marshalling aspects (message serialization / unserialization). The marshalling process implemented in the stub has been extended so that the objects are able to communicate from a CPU core to another one using simple communication mechanisms based on shared memory for passing the messages and spin locks based on the LEON3 atomic compare-and-swap operation (CASA instruction) to make safe the inter-core concurrent access to the memory.

The dual-core AMP architecture of the N-DPU ASW means that two applications coexist.

The first application, which acts as the master, is deployed on the LEON3-FT CPU core #0 and is in charge of managing the ICU interfaces (telecommand and telemetry packets), processing the data of camera #A, managing modes and technical services. This first application is made up of 20 realtime tasks.

The second application is deployed on the LEON3-FT CPU core #1 and is in charge of processing the data of camera #B and scrubbing the memory. This second application is made up of 8 realtime tasks.

N-DPU Application Software Dual Core Architecture
N-DPU Application Software Dual Core Architecture


A real-time software

In terms of real-time sequencing, the fundamental period to consider is 6.25 seconds: the software receives every 6.25s a new set of star windows to process. The transmission of these star windows is spread over the 4.1 seconds corresponding to the readout of the detector (1). Up to 25 packets of 32 kilobytes are transmitted per second by the camera over the readout period. At the end of the packet reception, the software has to extract the window segments from the packets and reconstruct the windows in less than 2.15 seconds, that is to say before the end of the cycle of 6.25 seconds (2). Once the reconstruction phase is complete, the software can start the photometric processing. These photometric treatments are carried out during the transmission of the star windows of the next detector and must imperatively be finished 4.1 seconds after the starting of the following cycle (3).

PLATO N-DPU ASW timeline
PLATO N-DPU ASW timeline


During the observation mode, both applications communicate through the circular buffers containing the telemetry packets. The second application builds the telemetry packets corresponding to the data from camera B and stores them in a shared queue. The first application retrieves these packets from the shared queue and transmits them to the ICU. There can also be inter-core message exchanges when, for example, an event is detected by the second application and a report must be transmitted by the first application.

 N-DPU application software GSE

The PLATO N-DPU Application Software GSE (Ground Support Equipment) are a set of hardware and software components used for validating the N-DPU ASW and testing the MEU system.

The GSE software part is based on the GAUSS platform (Generic Api for ground Support Software), a project developed at LESIA, which offers generic and flexible GSE features:

  • SpaceCraft interface simulator
  • System commanding (TC script editor)
  • TM visualization and monitoring
  • Assertion language for automatic test checking
  • Distributed architecture
  • SQL Database management

In addition to these software components, the PLATO N-DPU Application Software GSE also contain several hardware components:

  • STAR-Dundee SpaceWire Bricks
  • PLATO camera simulator (SIMUCAM) provided by the MAUA Institute (IMT, SĂŁo Paulo)
PLATO N-DPU Application Software GSE
PLATO N-DPU Application Software GSE


Tool for monitoring the TC/TM packets
Tool for monitoring the TC/TM packets


ASW N-DPU ASW Test Bench
ASW N-DPU ASW Test Bench


 Key Dates

Date Event
July 2014 PLATO selection by ESA
March 2016 N-DPU ASW development kick-off
June 2017 PLATO "adoption" by ESA
September to December 2018 Software SRR (System Requirement Review)
September to December 2019 Software PDR (Preliminary Design Review)
July 2020 Delivery to the PLATO consortium of PLATO N-DPU ASW V0.4 (full-image calibration mode)
July 2021 Delivery to the PLATO consortium of PLATO N-DPU ASW V0.8 (window calibration mode)
September 2022 Delivery to the PLATO consortium of PLATO N-DPU ASW V0.9 (science services partially implemented)
October to December 2022 Software CDR (Critical Design Review)
September 2023 Delivery to the PLATO consortium of PLATO N-DPU ASW V1.0 (100% of functionalities are implemented)

 People involved in the N-DPU flight software project

Name Role
Aliocha Amerge Flight software development (trainee)
Gaele Barbary MEU functional testing
Kimberley Berisha Flight software development (trainee)
Alexandre Crignola GSE software development (ASTEK)
Florent Ducellier Flight software specification and validation (ASTEK)
Gary Gabriel GERICOS framework development
Nicolas Gauthier Flight software development
Loic Gueguen GSE software management
Pierre-Vincent Gouel Flight software development
Baptiste Gouesbet Flight software development (ASTEK)
Lee-Roy Malac-Allain Flight software development
Aymeric Menager Flight software development (trainee)
Thibault Lamborot GSE software development
Gaelle Palandri GSE software development
Philippe Plasson Project management
Hugo Pompougnac Flight software development (trainee)
William Recart Flight software product assurance management (Hensoldt Space Consulting)

Contact : Philippe Plasson