2.1.

Instrument Principle

SO/PHI images the Sun with two different optical paths.¹⁶ One of the paths images the full solar disk at any point along the orbit, called the full disk telescope [with a 2° field of view (FOV)], while the other collects data with high spatial resolution, named the high-resolution telescope (HRT, with a 0.28° FOV).¹⁷ The optical path of the HRT is additionally equipped with an image stabilization system, consisting of a correlation tracker camera and a tip-tilt mirror. Each optical path has its polarization modulation package, containing nematic liquid crystal variable retarders and a linear polarizer, to transform the polarization signals into intensity levels.¹⁸ Both paths scan the photospheric line through a common narrow-band tunable filter system.^2,19 Finally, they lead to the common focal plane assembly (FPA), where the images are recorded on $2048\times 2048\text{pixels}$ by a custom-built active pixel sensor (also referred to as CMOS sensor). Both apertures penetrate the heat shield of the spacecraft and are protected by a heat rejection entrance window, which filters out all spectral components of the solar light outside of a 30-nm passband around the observed absorption line.

A science data set recorded by SO/PHI can be described by the following equation:

$\mathit{M}$ is the polarimetric modulation matrix, a $4\times 4$ matrix of images, describing how the instrument transforms the polarization degrees of incoming sunlight into practically measurable light levels (intensities) for each pixel of its FOV, $\mathit{A}$ are optical aberrations SO/PHI introduces, ${\mathit{I}}^{\text{flat}}$ are the flat fields (gain tables) of the telescope, depending both on wavelength and polarization states, $c$ is a constant gain factor that converts the pixels from number of photons accumulated on the detector to digital numbers (DN-s), and $I^{\text{dark}}$ is the dark field of the sensor in DN-s, the same for all wavelengths and polarization states. For further details on solar spectropolarimetry see Ref. 3.

2.2.

Data Processing Hardware

All data processing in SO/PHI is implemented in the DPU,^21–23 see Fig. 1. The DPU integrates a Leon-3FT microprocessor inside a GR712RC as central processing unit (CPU) which is a radiation-hardened processor by Gaisler, a Microsemi RTAX field-programmable gate array (FPGA) and two static random-access memory-based Xilinx Virtex-4 FPGAs, communicating through a SoCWire^24,25 network. The microprocessor is designated as the system controller, running the Real-Time Executive for Multiprocessor Systems²⁶ operating system, in version 4.10, implementing communications with the spacecraft, controlling image processing and memory transfers. The Microsemi FPGA is radiation hardened, and it implements the essential functions for the instrument (e.g., communication interfaces). It also acts as the system supervisor for the configuration of the reconfigurable Xilinx Virtex-4 FPGAs (RFPGAs) that are reconfigured dynamically during processing. The RFPGAs are used for data processing, compression, data accumulation and image stabilization in a time-sharing approach, saving volume, mass, and energy.

Fig. 1

The data processing of SO/PHI is performed on the DPU hardware. It runs distributed between a Leon-3FT microprocessor and two Xilinx Virtex-4 FPGAs. These processing units are aided by memories of different capacities. For long term data storage, a large capacity non-volatile memory is available.

The memory budget of the DPU consists of memories aiding processing and non-volatile memory facilitating storage. A 256-MiB memory is attached to the system controller, of which 128 MiB are available to use for image processing. A 1-GiB fast synchronous dynamic random-access memory (SDRAM) supports the RFPGA designated for data pre-processing. A 512-GiB non-volatile NAND-Flash image data storage is available for storing the raw images awaiting processing, and the final products waiting for the last steps performed by the instrument: compression, packaging of telemetry packets, and transmission to the spacecraft platform.

2.3.

Instrument Operations

SO implements an off-line commanding strategy. This strategy places the outline of commands and the establishment of final command parameters ahead of operations. They are defined in an iterative process, in a time frame of seven months to one week prior to their execution. Nominally, SO/PHI acquires data during three observation windows along one orbit, each of these windows lasting for 10 days. These windows are placed at special points of interests: closest approach and maximum and minimum solar latitude. There is a calibration campaign associated with each observation window, and a dedicated data processing campaign, taking place after the observations, and may last for the rest of the orbit. The operational constraints of the spacecraft require SO/PHI to anticipate its power, produced telemetry, electromagnetic compatibility, and time budget for all its operations. Consequently, all operations are planned and commanded from ground without autonomous decisions regarding the processing steps.

4.1.

Software Architecture

The data processing software is organized on three layers, see Fig. 3. The lowermost layer (primitives) implements the image processing functions, e.g., addition of images or Fourier transform of an image. These are implemented both as RFPGA functionalities³² and as software functions running on the system controller microprocessor. Due to the large number of functions one RFPGA configuration is not sufficient, therefore the RFPGA is reconfigured on demand, during the processing. The necessity for reconfiguration is determined by the on-board software when there is a call to a function that is not available in the currently loaded configuration.

Fig. 3

The data processing software is organized on three layers. This organization facilitates information hiding, and the removal of responsibilities from the application developer (task descriptor).

The second abstraction layer (operations) hides hardware details from the application and implements other lower-level functionalities. It integrates the primitives into image processing operations, hiding the hardware details. The image processing operations record metadata directly from this layer to improve metadata collection completeness by removing the full responsibility from the application developer. This layer also provides the functions for data transfer between different memories, and the functions for recording and storing metadata.

The application layer is where the processing functionalities are described, through user defined programs (UDPs). The UDPs are a special category of applications that are not compiled into the on-board software but handled by a UDP manager. Therefore, uploading a new UDP does not require a full on-board software exchange (on-board software is possible through UDP exchanges, full on-board software exchange, or FPGA configuration exchanges). The application layer further logs metadata, containing information that is only known on higher layers (e.g., the division of images performed is part of the flat fielding of the data set with a given ID).

We use three different languages in the architecture. On the primitives layer, the RFPGA firmware is described in Very High-Speed Integrated Circuit Hardware Description Language. The corresponding software functions in the same layer, and the operations layer is written in C. The application layer is written in On-board Command Language (OCL),³³ a high-level programming language based on C implemented for space instrumentation.

4.2.

Pipeline Construction

To unify the approach to data processing, all of its three functionalities (science observables processing, calibration data calculation, and determination of operational parameters) are implemented in form of pipelines. We extend the definition of a pipeline to a series of changes done to a target (a data set, a number of data sets, or a subset of a data set), resulting either in parameters, or a new data set and their associated metadata. Observed data sets are available in the non-volatile data storage. The data sets are identified by a data set ID and each has a metadata file associated with them. They may contain multiple images, e.g., different wavelengths and polarization states in the case of a science observation, or different focal positions in case of a focusing observation. The pipelines are implemented in the application layer, and therefore are written in the form of UDPs. A block approach is adapted in its definition to achieve the required flexibility.

A pipeline block is defined as a unit that executes a number of functions on its input data, forming a logical unit and writes dedicated metadata. The abstraction level of a block is decided from case to case. In respect to Fig. 2, some blocks are defined as much smaller functionalities that are performed more often, e.g., store data to non-volatile memory and can be added anywhere in the pipeline. In other cases, some of the separate blocks are combined, e.g., all Fourier space operations are performed in one block to avoid multiple Fourier transforms of the data set. To support their combination in multiple ways, a unified block interface is defined. Within a pipeline, blocks have a common target: a data set or part of a data set that is loaded into the processing memory. A block may load additional data for the processing step as needed (e.g., demodulation matrix), which is not written back to the non-volatile memory or passed to further blocks. Therefore all changes done to it are lost after the block. Due to the possibility of different combination of the blocks, the history of the data set inside each block must be determined, for which the interface is through the metadata file (e.g., if we cropped our data set in the first step, we also need to crop our dark field to the same area of the detector).

All pipelines are built by combining pipeline blocks into a processing sequence. They execute the blocks sequentially, i.e. continuing to a new block is possible only once the previous block is finished. Each pipeline also writes metadata specific to it and finally stores the metadata file into the non-volatile memory. The way pipelines are built is also specific to their memory needs and available memory on the two different platforms we run them on (RFPGA or only system controller). In some cases, this means running the sequence of blocks several times, with different subsets of the data set, and in some other cases to split a pipeline into parts, executed one after another.

To show how a pipeline is formed in the system described, we take an example for a science data processing pipeline (see Fig. 4). To cope with processing memory limitations, the pipeline is split into two parts: an image linear part, which processes a number of images of the data set at once, and into an image parallel part, which processes a number of rows of all images of the data set. This is necessary because we have operations that require the full image (e.g., a Fourier transform), and operations that require pixels from several images at once (e.g., polarimetric demodulation, RTE inversion). The two pipelines are executed $nl$ and $np$ times, respectively, both being equal to 1 in the nominal case, when we use the RFPGAs. We also show the implementation details of the dark field correction block, as an example.

Fig. 4

Example science data processing pipeline. The pipeline is split into two parts to enable its execution with memory budget restriction. The image linear part processes a number of images at a time, the image parallel part processes a number of rows of all 24 images at the same time. The parameters $nl$ and $np$ are the number of times the image linear and image parallel portion of the pipeline has to run to process the whole data set, respectively. In the implementation detail of the dark field, $ni$ denotes the number of images processed.

4.3.

Data Scaling

As a method for saving resources, a 24.8 fixed-point notation has been adapted for number representation during data processing, wherever possible (i.e., using a fixed number of 24 bits for the integer part, and 8 bits for the decimal part). Due to this, in all operations performed on the data, the accuracy must be optimized, considering the number of bits on which both the input and the result are represented. This varies from case to case; therefore, a uniform interface is defined for all pipeline blocks (target is scaled up to the most possible bits). All scaling necessary for maintaining accuracy in the process is performed inside the blocks, returning to the same scaling in the end. The obtained accuracy with this scheme is investigated in Ref. 34.

The single frames are obtained from the FPA in 12-bits digital depth, filling the detector well to a predefined level. The correct filling of the detector well is ensured by the exposure time calibration. A number of frames are accumulated into an image (the number of accumulations is determined by the required signal-to-noise ratio), then the image is shifted to the left by 8 bits, which are the decimal part of the numbers, all 0 at this time. Therefore, a raw data set is represented effectively on 12.8-bits digital depth, multiplied by the number of accumulations. This value is written into the metadata, and based on this, at the beginning of the pipeline we calculate the shift necessary to have all its images effectively represented on 23.8 bits (reserving a bit for sign). This scaling is already applied during the loading of the data set into the processing memory, ensuring the correct block interface.

There are three instances during the data processing, where the 24.8 fixed-point notation is abandoned: Fourier domain operations, the RTE inversion, and the compression. The Fourier domain operations are performed in floating-point, as the required accuracy could not be achieved by fixed-point implementation. The same is true for the RTE inversion. Both modules use IEEE 754 single-precision floating-point format. The reason for using 32 bits during the processing is to maximize the computational accuracy in the performed operations (e.g., divisions), however a 16-bit representation of the final results fulfils our requirements. Therefore, the images of the final result are represented on 16 bits, which is also the input to the compression module.

In the case of calibration data, the optimal scaling is ensured by the pipeline creating it. It is always represented on the fewest bits possible, while maintaining its required accuracy. The scaling is written into the metadata and read from there in the processing blocks that apply them to the science data set.

4.4.

Error Handling

Error handling is done on all software layers. The guiding principle is to find errors on the lowest possible levels, to isolate them, and to aid error search in case of failures. Table 1 summarizes the detected error types.

Table 1

Error detection and handling on the different software organization layers. Each organization layer (see Fig. 3) implements error detection, with the objective of finding the errors as low in the hierarchy as possible. Based on the severity of the error, they are classified into Errors and Warnings, and different actions are taken at their detection.

On the layer of the Primitives, it is ensured that the image processing functions do not return overflows as valid numbers. This is done by replacing these pixels with a value defined as not a number (NaN), assigned to the lowest negative number on 32 bits ($0\times 80000000$, in two-s complement). On the same layer, it is also made sure that these values are not treated as numbers (e.g., division of a NaN with any number results in NaN). NaN-s may be replaced later through the interpolation of surrounding pixels; therefore, we keep track of all generated NaN-s in a bit mask image, along with other information regarding the data set (e.g., magnetic signal strength, pixels outside solar disk). This mask in the end is encoded into the final results of the pipeline through pixel values that could otherwise not appear (e.g., negative or NaN values) to obtain the information on ground without adding to the data volume.

In the operation layer, it is made sure that the inputs to the primitive functions are valid. For example, we check that we do not address any invalid memory positions by calculating the end address of a data set based on the start address and the size of the data.

The application layer is responsible for ensuring that the data sent to the lower layers is meaningful, e.g., that the target image has the same integration time as the dark field or that the flat field had no errors during its generation. It is also on the application layer that the parameters received in the pipeline are verified, e.g., that the target data set of the science data processing pipeline is raw data and contains the expected number of images. Additionally, also on this level, errors related to the solar scene are detected (e.g., when a flat field with the required precision cannot be obtained due to a sunspot in the FOV during the calibration window).

Each function has a return parameter, indicating warnings and errors detected by it. Warnings are small failures that do not affect the execution of the pipeline and are only recorded in the metadata of the data set for evaluation on ground. Errors are problems that make it impossible or meaningless for the pipeline to continue (e.g., no data set with the specified ID was found). In case of error, the execution is interrupted, the metadata is saved, and the instrument continues with the execution of the next command that was received from ground.

4.5.

Metadata Management

The metadata of a data set comes from different sources.

The information from the planning process and calibration campaign is collected in a so-called Processing Environment, describing all information necessary for processing a science data set. This is written into the metadata of the data set at the time of its acquisition, also complemented by the instrument parameters. It is this metadata that is read and appended during the processing of the data set. Furthermore, we may override the Processing Environment written into the data set with the current one set on-board, if the processing plan changes later on.

The metadata generated during processing is created on multiple organization levels to ensure completeness. It is always recorded into metadata entries, each entry being part of one of the following categories.

Each metadata entry starts with an ID, marking its category. In the case of the first two categories, the data that follows indicate the operation or UDP executed, its target, the input parameters, and return value. The data summary entry records the start and end indices of processed images within the target data set, and information about which part of the sensor the data belongs to, how it was binned and scaled, and data type and format. At the recording of each metadata entry a time-stamp is added automatically.

More information and an example on the usage of the metadata are detailed in Ref. 35.

5.1.

Input Data

Data from the Helioseismic and Magnetic Imager on-board the Solar Dynamics Observatory (SDO/HMI)¹² is used to generate the input data set to the pipeline. SDO/HMI investigates the same absorption line, and the data are further processed with the SO/PHI Software siMulator (SOPHISM),³⁷ to produce a Stokes vector as similar as possible to one that SO/PHI would obtain, in $2048\times 2048\text{pixel}$ resolution, see Fig. 5. There is one important difference, however, that the wavelength sampling of HMI is different, which is not taken into consideration during the pipeline execution. Therefore, the results are expected to contain some errors due to this approximation. Furthermore, the data set used is of a lower level, and neither the filter profiles nor the spacecraft velocity is removed, therefore, we expect an error in the $v_{\text{LOS}}$. These images are further manipulated to represent the raw observables, approximating Eq. (1), according to the following equation:

Fig. 5

Test data set at the third wavelength sample. (a) The input to the pipeline are the Stokes images from SO/PHI Software siMulator (SOPHISM).³⁷ (b) The input images are obtained applying Eq. (5) and show similar light levels in all polarization states as a result of the modulation. The data also show the effect of the dark field (stripes) and the flat field (smudges and dust grains).

The calibration data applied is recorded in the laboratory, using the flight model of SO/PHI, and is shown in Fig. 6. The dark field, acquired in a dark chamber, shows the characteristic sensor pattern: the four distinct horizontal stripes, created using four different channels for image read-out. The flat field has been recorded with the use of a lamp to ensure the most uniform illumination possible. It shows a gradient pattern and a number of dust grains inside the instrument. It has been normalized to its mean intensity, then scaled to be represented on 10 bits total, translating to 2 bits integer and 8 bits decimal part in the fixed-point notation. The demodulation matrix has been determined during the ground calibration campaign with the use of a polarization calibration unit (described in Ref. 38). Its field dependence varies with a standard deviation between $5·{10}^{-9}$ (for ${\mathbf{D}}_{\mathrm{1,3}}$) and 1.12 (for ${\mathbf{D}}_{\mathrm{4,1}}$).

Fig. 6

The calibration data used in the test run were recorded in the laboratory. (a) The dark field shows the characteristic sensor pattern: four distinct vertical stripes due to the four different read-out channels. (b) The flat field used in the tests shows a gradient across the FOV, and a few dust-grains. (c) The $4\times 4$ demodulation matrix, $\mathit{D}$, depends on the FOV. To show this dependence in the plot, we subtract from each of the elements their spatial mean.

5.2.

Output Data

We execute the full pipeline on the data set in the nominal configuration, processing all images at the same time. As we do not induce any cross-talk effects into the test data, we set the corresponding parameters to 0, and in consequence, the two cross-talk correction blocks from Fig. 4 do not execute. In this test, we configure the RTE inversion to determine all possible output images it can provide. In regular operations, we set the output of the inversion to be only the four images of interest ($\mathit{B}$ = ($|\mathit{B}|$, $\gamma$, $\varphi$), and $v_{\mathrm{LOS}}$), however, the inversion module is able to return nine parameters in total. For comparison, we also execute the image linear part of the pipeline in back-up configuration, processing four images at a time. This run creates six different output data sets, each containing a subset of the full result.

The result of the pre-processing [see Fig. 7, calculated according to Eqs. (2) and (3)] is $\mathit{S}$, which will be the input to the RTE inversion. After the dark- and flat-field correction, the solar scene is undisturbed by instrumental artefacts. In areas of low illumination levels (e.g., dust grains on the sensor, or areas masked by a field stop), NaN-s are produced during the flat-field correction through division by zero. In an ideal flat field, all pixels located behind the field stop would be 0, resulting in an area of uniform NaN-s in the corners after the division. However, due to the imperfection of the dark-field correction, some pixels reach sufficiently large values to not produce a NaN. The Stokes vector, obtained after the polarimetric demodulation, differs slightly from $\mathit{S}$ in Eq. (5) due to the limited numerical accuracy. These images already show the presence of the magnetic field, which will be quantified by the inversion of the RTE.

Fig. 7

Step-wise results of the pre-processing on the input data set from Fig. 5. (a) The third wavelength sample in the four different polarization states (4 out of 24 images) after dark- and flat-field correction of ${\mathit{I}}_{\lambda }^{\text{recorded}}(x,y)$, see Eq. (2). The white pixels in the image corners are NaN-s produced during the processing through division by sufficiently small numbers to produce an overflow. (b) Result of the pre-processing, the third wavelength sample of the normalized Stokes vector (4 out of 24 images), see Eq. (3).

The final results of the pipeline are the continuum intensity and the results of the RTE inversion: the magnetic field vector $\mathit{B}=(|\mathit{B}|,\gamma ,\varphi )$, described through its magnitude, azimuth and inclination, and $v_{\mathrm{LOS}}$ (see Fig. 8). All values outside of the solar disk are meaningless for the RTE inversion, therefore, it cannot converge, resulting in noise as output. The $|\mathit{B}|$ is stronger in the umbra of the active region and weaker in the penumbra as expected. In $\gamma$, we can see the opposing polarities that compose the active region, while $\varphi$ shows the fan-like pattern, originating in the center of the round magnetic features, consistent with the orientation of the magnetic field in such features. The $v_{\mathrm{LOS}}$ over the full disk shows the spectral shift due to the rotation of the Sun and the spacecraft velocity, on top of the intrinsic shifts due to plasma motion. The slight bias to one side is due to the lack of filter profile corrections in the used SDO/HMI data set. The $v_{\mathrm{LOS}}$ in the active region shows strong flows of opposing directions in the penumbra, known as Evershed flows,³⁹ driven by the magnetic activity. We analyze the accuracy of the pipeline in Ref. 34.

Fig. 8

(a) The five resulting images from the full pipeline, continuum intensity ($I_c$), the components of the magnetic field vector $\mathit{B}$ = ($|\mathit{B}|$, $\gamma$, $\varphi$), and the LOS velocity, $v_{\mathrm{LOS}}$. $v_{\text{LOS}}$ is plotted on a scale centered around the spacecraft velocity, $-0.9\mathrm{km}/\mathrm{s}$ ($⟨v_{\mathrm{LOS}}⟩$ at disk center). The circular contour marks the solar limb, and the square shows the region magnified in the next row. (b) Detail of the full FOV, showing the active region. The $v_{\mathrm{LOS}}$ was corrected for the mean quiet Sun intensity in this region.

On ground, the image data and associated metadata are converted into files according to the Flexible Image Transport System.⁴⁰ While the metadata on-board is written into a continuous unit, the converter separates the header entries into separate American Standard Code for Information Interchange tables based on their origin. The metadata associated with the processing, recorded from UDP level, reflects the steps taken by the pipeline, its parametrization, and shows the success of the blocks (see Tables 2 and 3). Based on this table, we also have an overview of any warnings or failures during the execution. The metadata recorded during the dark fielding block from operation level reflects the implementation shown in Fig. 4, giving an insight into the lower-level information that we can access (see Table 4). See Ref. 35 for more detail on the usage of metadata.

Table 2

Excerpt of metadata recorded from UDP level, during nominal execution of the pipeline, showing all steps taken, and their parameters. In cases where we have more parameters than what can be recorded in one entry, several entries are added by the same UDP. The timestamp shows the on-board time during the execution. The return value shows success in most cases (0), with some steps creating NaN pixels in the result (10). The start and end indices show that the full data set is processed at once, and how the number of images changes during the processing through extension with the mask, the inversion, and the encoding of the mask into the Ic image.

Table 3

Excerpt of metadata recorded from UDP level, during the execution of the linear part of the pipeline in back-up configuration. In this configuration we process four images at a time and obtain six output data sets. Here we show the metadata of the first one of the six. The entries indicate that the first four images have been loaded (indices 0 to 3) with full FOV (0 to 2047), extended during the processing with the mask image, index 4.

Table 4

Excerpt of metadata recorded on operation level by the dark field subtraction block, during nominal execution of the pipeline, see Fig. 4. The return values all show success (0). The processing memory addresses show that the dark field is loaded to the address 419430400, scaled to match the target in the same location, then it is subtracted from each image of the target data set (loaded to address 0). There are 24 entries for subtraction in total (four shown here), each recording the increment of addresses from image to image in the target data set. The scalar input values show the dark-field ID and the scale factor.

5.3.

System Metrics

The CPU load during the processing reflects the pipeline implementation and the underlying on-board software (see Figs. 9 and 10). These profiles are dominated by the memory transfers and the image processing operations, together with the necessary RFPGA related actions. Whenever reading the non-volatile memory, the DPU used 100% due to a background task that polls the queue of the non-volatile storage to transmit the next data chunks. As soon as everything is in the queue, the load drops to a lower level, until the transfer is finished. In case of writing to the non-volatile memory, the system controller is in full control of the data transfer, eliminating the need for synchronization. Therefore, it can write at 100% capacity, which is also the reason that it takes shorter time than reading. This is the reason for the nominal configuration to show 100% load at memory transfers between the non-volatile storage and RAM #2. Transferring from non-volatile memory to RAM #1 shows a different load profile due to the different implementation of the data transfer. In this case, the non-volatile memory controller waits for a confirmation from the system controller before transmitting a new chunk, resulting in a slower transfer (the case of the back-up configuration). During RFPGA configurations, the CPU load is high ($\sim 95\%$), creating peaks at each reconfiguration. The system controller runs the image processing pipeline in parallel with a scrubbing task, that uses all idle time to rewrite the RFPGA configurations part by part to defend against radiation effects. This keeps the CPU load high even during times when a low load would be expected otherwise (e.g., during the RTE inversion, performed by the RFPGA, the combination of the scrubbing and the memory transfers keeps the load high). In the case of the back-up configuration, image processing functions run on the DPU, and use its full capacity.

Fig. 9

CPU load during the execution of the (a) image linear and (b, c) image parallel pipelines in nominal configuration. The colours show the execution of different pipeline blocks (see Fig. 4). The red dotted lines with diamonds indicate the times of RFPGA reconfigurations. During the polarimetric demodulation, there are 12 reconfigurations, which will be entirely removed in the future. The full pipeline takes little over 1.5 h to complete.

Fig. 10

CPU load during the image linear pipeline execution in back-up configuration. The colours indicate the execution of different pipeline blocks (see Fig. 4). In back-up mode, we only process four images of the full data set at a time, due to the size limitation of RAM #1. Therefore, the pipeline executes a loop, repeating the block sequence “Load target, Subtr. dark, Divide flat, and Store, Metadata rec.” six times in total (only three shown). The image linear part runs in a little over 1.5 h in back-up mode, a significant time increase compared to nominal mode.

The run-time of the pipeline is significantly shorter in the nominal configuration than in back-up mode. We measure it by extracting the number of processor ticks occurred during the execution, where one tick corresponds to 2.5 ms. To execute the image linear pipeline in nominal mode takes just over 2 min, while the image parallel pipeline takes a little over 90 min. The majority of the processing time is made up by RTE inversion block, the duration of which varies based on the science mode it operates in. The configuration used during this test writes all nine possible outputs, while if we choose only the four results of interest (as aimed to be configured in nominal mission phase), it runs $\sim 30\min$ faster. Moreover, the desired implementation of the inversion is to read the data from the RAM #2 and write the results to the non-volatile memory, from where they will be read back to the RAM #2 to continue their processing. However, the current implementation writes the data in chunks from the RAM #2 to RAM #1, the RTE inversion module reads the input from here and writes the results to the same memory, which are then read back to the RAM #2. This implementation introduces additional data transfer operations of the input data, transfers between different memories which have longer transfer time and prohibits parallel read and write operations which would be possible if the input and output were transferred between different memories. In this setup, the time of the inversion itself (together with reading and writing RAM #1) is 71.41 min, the time of the input data transfer from RAM #2 to RAM #1 is 10.88 min, while the time of the output data transfer from RAM #1 to RAM #2 is 2.7 min.

The RFPGA configurations are optimized to reduce the execution time by minimizing the number of reconfigurations during science data processing (each reconfiguration takes between 2 and 4 s). There is none necessary during the linear pipeline, while in the parallel pipeline, there are five reconfigurations outside of the polarimetric demodulation block, which has twelve. This latter block requires such a high number, because the matrix multiplication is in a separate configuration. However, this operation will be re-implemented in the future as a UDP, calling other low-level operations, eliminating all reconfigurations in the polarimetric demodulation block. Time wise, this will save the reconfiguration times (12 times 3 s on average), this final implementation has been measured to execute in 92 s for a full data set.⁴¹

Running the full pipeline in the nominal mode with all nine possible outputs, on the full FOV, requires a little over 1.5 h. This time is reduced to close to 1 h when we store only the four outputs of interest: the three components of the magnetic field vector and the flow velocities. This is the time required for processing each of the acquired data sets, which may amount to several hundred in each orbit. This time may further be reduced by cropping and binning, depending on science case.

In contrast, the linear pipeline runs in over 90 min in back-up configuration. This increase originates both from the longer execution time of the primitive functions and the longer memory transfer times (between the non-volatile memory and RAM #1). This large increase indicates that the execution of the full pre-processing in back-up configuration would have a significant influence on the science operations.