1 Introduction

A solar flare is a sudden brightening seen on the Sun that may last for several minutes to a few hours. The first recorded observation of a solar flare happened in 1859, when Richard Carrington observed this amazing phenomenon in white light (Carrington, 1859). Since then, solar flares have been observed over a wide range of the electromagnetic spectrum using ground-based and space-based telescopes. In recent decades, with the advancement of space-based observatories, solar flares are observed in high-energy wavebands in the UV, X-rays, etc., complementing observations made in visible and IR by ground-based telescopes. Various space-based telescopes such as the Extreme Ultra-Violet Imaging Telescope onboard the Solar and Heliospheric Observatory (SOHO: Delaboudinière et al., 1995), the Extreme Ultraviolet Imager (EUVI) onboard the Solar Terrestrial Relations Observatory (STEREO: Wuelser et al., 2004), the Atmospheric Imaging Assembly (AIA) onboard the Solar Dynamics Observatory (SDO: Lemen et al., 2012), and the Interface Region Imaging Spectrograph (IRIS: De Pontieu et al., 2014) provide broad coverage in the UV. Despite that, observations in the near ultra-violet wavelength range (200 – 400 nm) are relatively minimal. IRIS operates in this wavelength range, but is limited in temporal and spatial coverage. Also, the raster images have a limited field of view of 60 × 60 arcseconds. So, currently, high-cadence flare images in the near-UV wavelengths are limited. This advocates for an NUV imaging telescope to fill this void. The Solar Ultraviolet Imaging Telescope (SUIT) is expected to play a crucial role in this context.

The Solar Ultraviolet Imaging Telescope (SUIT: Ghosh et al., 2016) is a payload on the upcoming space-based solar observatory Aditya-L1 (Seetha and Megala, 2017). As the name suggests, SUIT will be imaging the Sun in the near-ultraviolet range (200 – 400 nm) in eleven spectral bands, using narrow and medium band spectral filters covering a field of view (FOV) of ±1.5 R⊙ with a plate scale of \(0.7''\) pixel−1. SUIT uses a 4k × 4k back-illuminated CCD detector with four-channel simultaneous readout. Despite this simultaneous readout, it takes nearly 16 seconds to read the entire 4k × 4k frame at 280 kHz clocking frequency, which limits the temporal cadence. For observing highly dynamic events like solar flares, 16-second cadence (for single filter observations and much higher if multiple filters are used) is a severe limitation.

One of the methods to achieve faster cadence, with the same spatial resolution, is to reduce the number of pixels, which can significantly reduce the readout time. So, defining a region of interest (RoI) is an effective approach for high-cadence, high-resolution studies of localised events, such as an active region or solar flares, on the solar disk. However, dynamically detecting a localized event like a flare and finding its location onboard a space-based instrument is non-trivial. Since real-time access to the space-based instrument is impossible due to practical difficulties such as station visibility, and also predicting the exact time and the location of a solar flare is challenging; a flare RoI can neither be calculated promptly on the ground nor can be pre-decided and loaded onto the instrument in advance. This necessitates developing onboard decision-making intelligence to automatically detect a flare and find its location when it happens on the solar disk, and accordingly define the RoI, in real-time. To identify a flare, SUIT makes use of real-time data from two other X-ray payloads, namely the Solar Low Energy X-ray Spectrometer (SOLEXS) and High Energy L1 orbiting X-ray Spectrometer (HEL1OS) onboard the same observatory, Aditya-L1 (Sankarasubramanian et al., 2017).

The onboard-intelligence algorithm in SUIT is designed to address the following requirements:

  1. i)

    Identify occurrence of a solar flare, localise its position on the solar disk, define an RoI around the flaring location, and start observing the flare RoI for a specific amount of time (smaller RoI in high cadence).

  2. ii)

    Periodically update the readout area on the CCD corresponding to the RoI to correct for solar rotation during the observation. This requirement is to correct for solar rotation in case of long-duration flare observations using a small RoI.

  3. iii)

    Automatically adjust the exposure time based on the flare intensity to maintain optimum counts in the CCD pixels.

The above-mentioned requirements are realised by various modules that constitute the SUIT onboard-intelligence algorithm. The HEL1OS flare-trigger module continuously analyses the integrated hard X-ray data from the HEL1OS payload and identifies occurrence of a flare. The flare-detection-and-localization module is used to detect a flare and find its location on the full-disc image. Once the flare position is found by the flare detection and localization module, an RoI around the flare is selected and observed with higher cadence. During this observation, the flare intensity may increase many fold, especially for M- and X-class flares. In order to prevent CCD pixel saturation and get good contrast images, the exposure time of the images has to be adjusted automatically. The auto-exposure module changes the exposure time depending upon the image contrast. For the flare observations and other long-duration RoI observations, the RoI needs to be corrected continuously, taking into account the differential rotation of Sun. The RoI tracking module updates the RoI coordinates at regular intervals of time during the flare and other RoI observations using a pre-uploaded look-up table (LUT).

Several semi-automated techniques (Saba, Gaeng, and Tarbell, 2006; Gill, Fletcher, and Marshall, 2010) and fully automated techniques (the ones discussed in the article) have been developed and implemented in recent years for detecting and tracking solar features such as flares, active regions, coronal holes, CMEs, etc. The detection methods range from simple image-recognition methods based on intensity variations derived from running-difference images (Piazzesi et al., 2012), region-growing and edge-based techniques (Veronig et al., 2000), to more complex algorithms using machine learning (Fernandez Borda et al., 2002; Ahmed et al., 2013). The SDO Flare Detective (Grigis et al., 2010) finds the flare start time using light curves derived from macro-pixels. Solar Demon (Kraaikamp and Verbeeck, 2015) uses SDO/AIA images to detect flares, dimming, and EUV waves by tracking the increase/decrease in intensity in regions that are identified by thresholds. Yang et al. (2018) and Pötzi, Veronig, and Temmer (2018) also used similar region-based methods on H \(\alpha\) images for real-time flare detection. The RHESSI Flare Finder (Lin et al., 2002) searches for microflares as local maxima in the 6 – 12 keV count-rate timelines. The flare detection in Hinode is done using a tool called FLD (Flare Detector tool: Kano et al., 2008). This tool divides the image into 16×16 macro-pixels and then finds the increase in macro-pixel intensity by subtracting the image from a reference. In most of these methods, difference imaging is used to find increase in intensity. Use of difference imaging is also common in CME-detection techniques such as CACTus (Robbrecht and Berghmans, 2004), SEEDS (Olmedo et al., 2008), and ARTEMIS (Boursier et al., 2009). Patel et al. (2018) also used a simple image-difference technique to detect CMEs. This technique is going to be used onboard to detect CMEs in real time using the Visible Emission Line Coronagraph (VELC), which is a sister payload of SUIT.

As discussed above, there are several techniques used for flare detection and localization, but none of them are used for real-time detection in space. This makes the SUIT flare-detection and -localization algorithm unique. The method used for flare detection in SUIT is also based on image subtraction and is similar to the SoFAST automated flare-detection technique (Bonte et al., 2013). SoFAST uses EUV images from the PROBA2/SWAP EUV imager and performs image subtraction and thresholding of macro-pixelled image sequences. The region-identification technique, which is used in many of the other above mentioned algorithms, is a very efficient method for feature detection and extraction. However, it requires pre-processing of images to correct for bad pixels (flat-fielding) and limb-darkening, which makes its implementation onboard complicated due to the limitation in availability of resources. The flare detection and localization algorithm in SUIT performs image subtraction and converts these difference images into macro-pixels to look for increase in macro-pixel brightness. The image subtraction will nullify the effect of bad pixels and limb darkening. This method needs four consecutive images to detect a flare and localize it with high confidence.

The external triggers are generated using the data from the X-ray payloads HEL1OS and SOLEXS. The SOLEXS payload generates the trigger internally and provides it to SUIT, while the HEL1OS flare-trigger module, one of the major components of the SUIT onboard intelligence, generates the trigger independently from HEL1OS data. The HEL1OS flare-trigger module monitors the increase in flux in the time-series data and gives a flare trigger when the rise in the flux crosses a predefined intensity threshold. This is a common method used to define the start time of a flare from time-series data. In RHESSI, the count rate in 6 – 12 keV energy band is compared to a threshold, which is 3\(\sigma\) above the background level to detect the occurrence of a flare. The GOES flare start time as defined by NOAA is when four consecutive values in one-minute 1 – 8 Å data are strictly increasing, they all exceed the B1-threshold, and the last value is 1.4 times greater than the value three minutes earlier. Here, the one-minute data are the time-averaged data over a minute duration, and the B1 threshold is the peak flux of a B1-class flare, as defined by GOES.

The auto-exposure control modules used in XRT (Kano et al., 2008) change the exposure as well as use different thickness filters to reduce or increase input-light intensity. AIA (Lemen et al., 2012) and TRACE (Handy et al., 1999) use similar event-detection methods to measure image contrast for auto-exposure control. In SUIT, the automatic-exposure module is based on the number of pixels near saturation and the number of near-UV bright points (NUV BPs). NUV BPs are bright points observed in NUV wavelengths and are believed to be chromospheric features (Riethmüller et al., 2010; Grubecka et al., 2016). This method is very effective yet simple and easy to implement. The RoI tracking module changes the RoI coordinates according to the solar rotation, rather than actually identifying the region by its features and tracking it. This method uses a pre-calculated look up table (LUT) to update ROI coordinates.

Figure 1 shows a block diagram of the onboard-intelligence modules. The flare-localization module is called when any of the external triggers are high and also once every minute during normal observations, independent of the external-trigger status. Once the flare-localization module identifies and localizes a flare, the detected flare is observed for a specific amount of time (which is currently fixed as two hours and can be modified). The RoI tracking and auto-exposure control modules function during the flare-observation mode. The working principles of these algorithms are explained in Section 2. In Section 3, the testing of these algorithms using the available and synthetic data along with the efficiency results is discussed. In Section 4, the hardware module testing using a laboratory setup and corresponding results are presented. The final section summarizes the work, discusses the limitations of the algorithm, and concludes.

Figure 1
figure 1

Block diagram of the SUIT onboard-intelligence modules.

Full size image

2 Working Principles of the Onboard Intelligence Algorithm

2.1 HEL1OS Flare Trigger Generation Module

HEL1OS is one of the X-ray payloads onboard the Aditya-L1 mission. It will observe the Sun as a star in the 10 – 150 keV range using two different sets of detectors, viz. two cadmium telluride (CdTe) and two cadmium zinc telluride (CZT). These are wide-band gap semiconductor detectors with applications in X-ray and \(\gamma\)-ray detection. They provide good energy resolution, high detection efficiency, and room-temperature operation among the traditional high-energy compound detectors (Sordo et al., 2009). The integrated count rate from the two CdTe detectors is provided to SUIT. These data are used by the HEL1OS flare-trigger generation module to generate the flare trigger.

The main objective of the HEL1OS flare trigger module is to assist SUIT in faster detection and localization of flares by giving a head start on flare occurrence to the flare detection and localization algorithm. Whenever there is a rise in hard X-ray flux due to the occurrence of a flare, this module triggers the flare flag, which initiates the flare-localization module. The trigger-generation algorithm is explained in Figure 2 as a flowchart. The data from two HEL1OS detectors are combined along with their corresponding weights w1 and w2. These weights can be tuned post-launch depending on the noise characteristics of the channels. After the data are combined with the weights from the two detectors, the median of the data is taken, which is used by the algorithm. The median is calculated using the three latest data values. Depending on the median type chosen, either box-car median or normal median is calculated. Taking the median is required to avoid data corruption from noise spikes. If the rate of increase in flux is slow, the cadence of the data can be decreased using the skip number. The skip number determines the number of data values that must be skipped between two data values that are used for the median calculation. The algorithm uses this median data and checks for two conditions to be satisfied. These conditions determine if there is a continuous increase in flux using two different thresholds: Count Threshold and Flux Threshold. The Count Threshold is used to measure the duration of the continuous increase while the Flux Threshold measures the value of the total increase in flux during this time. A flare trigger is generated if the median data increases monotonically over a duration determined by count threshold and the overall increase in flux is greater than the flux threshold.

Figure 2
figure 2

Flow chart explaining the HEL1OS flare-trigger generation algorithm. The parameters w1, w2, Count Th, and Flux Th can be changed using telemetry. Flare trigger is generated if both Conditions 1 and 2 are satisfied.

Full size image

2.2 Flare Detection and Localization Module

The flare detection and localization module is used for the detection of the solar flare and finding its location on the solar disc, using SUIT images. It will use full-frame images binned on-chip by 2×2 pixels from SUIT Mg ii h (280.3 nm and 0.4 nm pass-band) filter. This module will be activated in the following two scenarios,

  1. i)

    After getting a trigger from the HEL1OS flare-trigger module or SOLEXS payload.

  2. ii)

    Once every minute during normal SUIT observations.

Although the algorithm used in these two scenarios is same, the cadence of images is different.

2.2.1 Flare Localization After External Triggers

Once the trigger is generated and received, the flare flag is raised and the flare-localization module is activated. This is referred to in this article as flare-localization after external triggers. Once the flare-localization module is activated, the on-going observation will be stopped and four consecutive, binned, full-disk images of the Sun in the Mg ii h narrow-band filter will be recorded. The decision to use four images for flare detection is taken after analysing AIA 1600 Å images. The flare-localization algorithm is tested by using different numbers of binned images, and the results are given in the Table 1. The results shown are obtained using 50 flare cases. It is evident that by using four images all 50 flares are detected correctly (true positives) and no flare is missed (no false negatives). When less than four images are used, there are false positives and when more than four images are used, some flares are missed. Thus, the flare-localization is most effective with four consecutive images (with image cadence of 24 seconds).

Table 1 The number of true positives, false positives, and false negatives obtained by running the flare-localization algorithm with 2-, 3-, 4-, and 5-image sets.
Full size table

The algorithm creates running-difference images using the four images binned by 2×2 pixels, with the first image as reference. The difference images are re-binned into a smaller number of super-pixels of size “sz”. With re-binning the flare evolution can be mostly restricted to a super-pixel. Then, the super-pixel with maximum intensity in each difference image is found and their location and intensity values are stored. The maximum value in each difference image must be greater than the pre-defined threshold values: Threshold 1, Threshold 2, and Threshold 3, each corresponding to the respective difference images (I2 – I1, I3 – I1, and I4 – I1). Also, the position of the three maximum values corresponding to these three difference images should lie within a one super-pixel neighborhood. If these two conditions are satisfied, the algorithm considers the position of the center of the maximum super-pixel in the third difference image as the flare position. If the flare position is well outside the solar disc (currently set as greater than 1.2 times the solar radius), it is considered as an artifact and will be neglected. After successful flare localization, the flare location is set as the RoI center for observation. After the RoI information is updated, SUIT will then switch to flare-observation mode, where the flare RoI is observed continuously for a long duration of time (which is currently set to two hours). If no significant increase of flux (no flare) is found from the first four images, one more Mg ii h image will be taken and the above process will be continued with the latest four images. This process will keep running until the flare is localized or for a fixed amount of time (currently set to ten minutes) that can be modified by tele-command. The SUIT flare-localization algorithm, activated by external trigger, is explained by the flow chart in Figure 3.

Figure 3
figure 3

Flow chart explaining the flare-localization algorithm with an external trigger. The flare-localization is successful if Conditions 1 and 2 are satisfied. If the flare location is found well outside the solar disc, they are neglected.

Full size image

2.2.2 Flare Localization from Self-Trigger

As part of the SUIT observation plan, full-disk images binned by 2×2 pixels of the Sun in the Mg ii h narrow-band filter will be captured and saved once every minute. After every new image is taken, the flare-detection-and-localization module is activated and the latest four images are used. The algorithm used is the same as the one used after an external trigger. The difference is that the external-trigger module is called only if an external flare-trigger is generated, while this module runs continuously as part of SUIT observations. This is referred to as flare-localization from self trigger. Since the image cadence is lower, the threshold values used will be higher than those used in flare-localization after external trigger.

2.3 RoI Tracking Module

In SUIT operations, the RoI is defined in two ways: Automatically decided and set by the onboard flare-localization algorithm due to occurrence of a flare, or up-linked from ground to the spacecraft, as the time-tagged tele-command for user-defined RoI observations. During the flare mode and RoI observation mode, the RoI is observed for a long duration. During this time, as the Sun rotates, the region of interest on the Sun moves; hence, the RoI coordinates have to be corrected accordingly. The Sun rotates differentially and the rotation rate is largest at the Equator and decreases with higher latitudes. The rotation rate can be estimated by Equation 1 (Snodgrass and Ulrich, 1990) where \(\omega\) is the rate of rotation in μrad sec−1 and \(\phi\) is the solar latitude.

$$ \omega= A + B \mathrm{sin}^{2}\phi+ C \mathrm{sin}^{4}\phi. $$
(1)

It would demand a lot of resources to calculate these values onboard in real time. Hence, these values are calculated for a range of latitudes and longitudes and uploaded as a look-up table (LUT). The onboard algorithm uses this LUT and tracks the RoI on the Sun. The RoI tracking algorithm is explained as a flowchart in Figure 4.

Figure 4
figure 4

Flow chart explaining the RoI tracking code. The RoI updating can be done after any specific interval of time. The LUT table is generated based on that interval, which currently is set to 30 minutes.

Full size image

A sample LUT, generated using Equation 1 on the CCD frame, is shown in Figure 5. The LUT calculation also considers the orientation of the solar rotation axis with respect to the CCD axis. Once the LUT values are calculated, they are arranged as a two-dimensional array. After every 30 minutes, new RoI coordinates are calculated based on the current RoI and the shift in RoI obtained from the LUT. A final LUT will be uploaded during the payload-verification phase of the mission after estimating the orientation of Sun’s rotation axis with respect to the CCD axis onboard. The orientation is not expected to change during the launch and the operation. If it changes, we have a provision to update the LUT corresponding to the new orientation through telecommands.

Figure 5
figure 5

An example of LUT, used by the tracking module. The values in each box correspond to average shift in X and Y required if RoI center falls in the region marked by the box. The solar disc is assumed to be at an angle of 30 degrees to CCD horizontal for this calculation.

Full size image

This LUT method can cause error in accurately correcting solar rotation due to the following limitations:

  1. i)

    Averaging of rotational velocity over 64×64 pixel box (45″). This averaging error will be greater towards the limb, as the box will cover a larger area (or range of latitudes) due to the projection effect.

  2. ii)

    Round-off error; as the shift values are rounded off to pixel units. Due to the projection effect, the shift will be in decimal units close to the limb side. The eastern limb has to be rounded to one pixel for sub-pixel shift values and west limb is rounded to zero.

The error accumulated due to the above-mentioned limitations is calculated in Section 3.3, and the implications of these errors on the observations are also discussed.

2.4 Automatic Exposure Control Module

During solar activities such as solar flares, the intensity in a local area on the solar disk can increase significantly from the pre-flare background and cause saturation of CCD pixels for a given exposure time. The location of the brightening (flare location) and the magnitude of the increase are totally unpredictable. Hence, an auto-exposure control module is required during such events as solar flares. It is also important that after the end of the flare and when the intensity is back to the pre-flare value, the exposure time has to be restored. The automatic-exposure control module decides the exposure time required for different science-filter combinations. This decision is based on Mg ii h image intensity levels. A set of exposure times, ranging from low to high, are defined and the auto-exposure module reduces or increases the exposure times within this set, depending on the conditions mentioned below:

  • Reducing the exposure time: If the number of pixels [N1] having count values greater than C1 in the image is larger than the set threshold [Th1], then the exposure time is reduced to the next lower value in the set.

  • Increasing the exposure time: If the number of pixels [N2] that have count values greater than C2 in the image is less than the set threshold [Th2], then the exposure time is increased to the next higher value in the set.

In case both conditions are met, then Condition 1 is given higher priority. Once the highest or lowest possible exposure time in the set is reached, the exposure time cannot be increased or decreased respectively, even if the corresponding conditions are satisfied. Figure 6 explains this algorithm as a flowchart.

Figure 6
figure 6

Algorithm used for the automatic exposure control. C1 and C2 are thresholds determining number of pixels, and Th1 and Th2 are value thresholds used for counting the pixels based on the pixel values.

Full size image

3 Testing the Onboard Intelligence Algorithm

The onboard-intelligence algorithm explained in Section 2 is tested using existing solar data. Also, additional data are simulated using the existing data to create a larger data set for testing the algorithms. All the modules for testing are written and tested in IDL. The results are analyzed and presented in the following sub-sections.

3.1 HEL1OS Trigger Generation Module

3.1.1 Testing Using RHESSI Hard X-Ray Data

The HEL1OS flare-trigger algorithm is tested using the Reuven Ramaty High Energy Solar Spectroscopic Imager (RHESSI) hard X-ray data in the 12 – 50 keV range. Light curves from 50 flares ranging from C- to X-class over the period 2010 to 2014 are used for the testing. The data have a cadence of four seconds, while the cadence of HEL1OS data those used by the algorithm is one second. Hence, the RHESSI data are interpolated using linear 1D interpolation using the IDL function interp1d and equivalent one-second cadence data are obtained. The free parameters (Median Type, Skip Number, Count Threshold, and Flux Threshold) are tuned to improve efficiency of the algorithm, for high detection rate and faster detection time. Medtype = 1 (Box car median) and skipnum = 0 (no data are skipped) are chosen as they are found to give maximum efficiency. The algorithm is successful in identifying all 50 flares with a median trigger-time to start-time difference of 192 seconds, with trigger coming after the GOES start time. The histogram of time differences between the GOES catalog start time and HEL1OS trigger time is shown in Figure 7.

Figure 7
figure 7

Comparison between HEL1OS algorithm trigger time and GOES catalog start time for 50 flare cases. A positive value means algorithm identifies the flare after GOES catalog start time.

Full size image

3.1.2 Testing Using Synthesized Light Curves

In order to test the HEL1OS trigger-generation algorithm with a broad range of light curves, HEL1OS-like light curves are simulated using the RHESSI data (12 – 50 keV) and HEL1OS expected peak and background values. The 50 RHESSI light curves that are used to test the algorithm are fitted with the function defined as

$$ f(t) = 0.5 \sqrt{\pi}AC \mathrm{e}^{D(B-t)+C^{2}D^{2}/4}[\mathrm{erf}(Z) - \mathrm{erf}(Z - t/c)] + E t + F , $$
(2)

where

$$ Z = (2B + C^{2}D)/2C $$
(3)

and erf is the error function defined as:

$$ \mathrm{erf}(t) = 2/\sqrt{\pi} \int_{0}^{t} \mathrm{e}^{-s^{2}} \mathrm{d}s $$
(4)

The error function was available as a pre-defined function in IDL. \(A, B, C\) are amplitude, peak position, and half-width of the Gaussian, respectively, \(D\) is exponential decay factor. \(E, F\) are the slope of the background function and the pre-flare background values, respectively. This function was derived by convolution of a Gaussian function and an exponential-decay function with an additional linear term to take into account the background variation during the flare, and it was used in a form suitable for numerical calculations, as given by Gryciuk et al. (2017). Figure 8 shows a sample RHESSI light curve fitted with the function. The free parameters, Gaussian width, and exponential decay factor, obtained by fitting 50 light curves with the function, are then used to synthesize additional light curves with the parameter range bound by the RHESSI light curves (Table 2). The synthesized light curves are normalized (scaled between 0 and 1). The normalized synthetic light curves are then scaled between the expected background value and the peak value of HEL1OS. In order to mimic the HEL1OS output, a noise equivalent to photon noise is added to the synthetic light curves. About 200 light curves are synthesized using the process described above. Figure 8 shows a sample synthesized light curve.

Figure 8
figure 8

On the left is a sample RHESSI flare light curve (in Red) fitted with the function given in Equation 2 (in Green). On the right is a sample synthesized flare light curve used for testing the HEL1OS flare trigger module. A: 20000, C: 200, and D: 0.005 are used for this fit.

Full size image
Table 2 Parameters and the corresponding ranges of values used to synthesize HEL1OS light curves. The parameter values are chosen so as to include all possible cases.
Full size table

The algorithm is run on these synthesized light curves and various performance parameters such as true positives, false negatives, and mean delay in generating trigger are calculated. True positives are successful detection and false negatives are failed detection. The mean delay is the average time taken for the trigger generation from the flare start time. Since these are simulated flare light curves, start times are defined manually. In this case, we defined the start time as \(B - 3C\) where \(B\) is the peak position and \(C\) is the half width of the function mentioned in Equation 2. The free parameters, Med Type and Skip Num, are tuned to obtain the best possible results. These test results are given in Table 3. This table gives an insight into how the detection time and probability of detection can be improved by tuning parameter values. The right set of parameters need to be chosen depending on the required specifications. For example, in Case 7 there is a \(16\%\) probability that trigger generation may fail and the mean delay in trigger generation is 80 seconds. In Case 8, the trigger generation is always successful, but the mean delay in trigger generation is 120 seconds. So, if we depend solely on this trigger for observation operations, we cannot afford to miss any triggers, and Case 8 would be a preferred option. If the objective is to get faster trigger generation time, at the cost of missing few flares, then the combination in Case 7 can be chosen. Since the values of these free parameters can be tuned post-launch, the final values will be decided during the initial phase of operation. It should be noted that the definition of start time is used just as a reference to compare the trigger time among various cases. It should be noted that there is no scientific significance in this start-time definition.

Table 3 Different combinations of Median Type and Skip Number used and the corresponding results obtained for each case.
Full size table

3.2 Testing of the Flare Localization Module Using SDO/AIA 1600 Å and IRIS Mg ii h Data

There are no full-disk data with high cadence (as comparable to SUIT) available to exactly match the Mg ii h images that will be used in SUIT for flare detection. Hence, the flare-localization algorithm is tested using SDO/AIA 1600 Å full-disc images with 24-second cadence, corresponding to 49 flares ranging from C-class to X-class. This particular band is chosen as the 160 nm is close to the SUIT operational range of 200 – 400 nm, and it is imaging upper chromosphere and transition regions of the Sun. The 4k × 4k SDO images are binned to 2×2 pixels and used for testing the flare-localization algorithm. The algorithm is able to successfully localize all 49 flares correctly after carefully tuning the thresholds. In order to quantify the efficiency of the algorithm with respect to Threshold-3, the True Skill Statistic (TSS) is calculated. The TSS calculation is done using the number of true positives (TP: flare predicted and observed), false positives (FP: flare predicted but not observed), true negatives (TN: no flare predicted and none observed), and false negatives (FN: no flare predicted but observed). The true positive rate (TPR) or sensitivity is the proportion of correctly classified flares out of all of the flares observed in the sample

$$ TPR = TP/ (TP + FN). $$
(5)

The true negative rate (TNR), or specificity, is the proportion of true negatives out of all the non-flaring instances. The false positive rate is

$$ FPR = 1 - TNR $$
(6)

and the false negative rate is

$$ FNR = 1 - TPR. $$
(7)

The true skill statistic (TSS) (Youden, 1950) combines the sensitivity and specificity by taking

$$ TSS = TPR + TNR - 1. $$
(8)

All these values are calculated for different values of Threshold-3, keeping Threshold-1 and Threshold-2 constant at 5,000 and 10,000, respectively, and presented in Table 4. These efficiency parameters are calculated by considering each set of four consecutive images in the flare data as one case. Total data corresponding to each flare are one-hour long and all the 49 flare data are used. Those images corresponding to the data from flare start time until the peak time are considered the true flare condition and anything outside this range is considered no flare condition, respectively. So, when the algorithm detects a flare inside the flare start time to peak time range, it is considered a true positive, and if it misses, it is considered a false negative. Similarly, any detection outside this range is considered a false positive and a non-detection is considered a true negative. As is seen in Table 4, higher threshold values generate more false negatives and fewer false positives, while lower threshold values generate fewer false negatives but more false positives. Since the flare-detection algorithm is run for a specific amount of time after an external trigger, false negatives do not necessarily mean that the flare is missed, but its detection is delayed. For example, even though the flare is not identified in the first four images, which gives a false negative, it could be detected in the next four images or later. However, a false positive means a flare is detected incorrectly and is observed for the next few hours. Hence, a higher threshold is recommended so that the algorithm produces very few false positives, even though there might be a delay in detection of flares in some cases. The threshold needs to be adjusted with a trade-off between delay in detection and false detection.

Table 4 TP, TN, FP, FN, TPR, TNR, and TSS of the algorithm for different values of Threshold 3. These values are derived to measure the efficiency of the algorithm.
Full size table

IRIS Mg ii h images are also used to find the flare-detection time, and a similar comparison is made. Figure 9 shows the corresponding histogram. It has to be noted that these IRIS images are RoI images of the flaring region and hence no localization of the flare is attempted in this case.

Figure 9
figure 9

Comparison of SUIT localization time estimated by flare-localization algorithm using IRIS Mg ii h images with GOES catalog start time. Positive value means that the algorithm identifies the flare after GOES catalog start time.

Full size image

3.3 Testing of the ROI Tracking Module Using SDO/AIA 1600 Å Data

SDO/AIA 1600 Å images are used for testing the RoI tracking module. A feature on the solar disc (such as an active region) is picked from the images and is tracked for a duration of two days using the algorithm. If the tracking algorithm is efficient, then the chosen solar feature should remain inside the RoI even after two days. The LUT table is calculated for the SDO/AIA 1600 Å data whose plate scale is 0.6 arcsec pixel−1 and solar N–S is aligned vertical to the CCD horizontal (along the row pixels). The RoI location is planned to be updated from the ground once every day. Hence, the maximum error that can accumulate in the RoI coordinates is for 24 hours. If required, the RoI location can be updated more frequently, multiple times per day using time-tagged commands. Figure 10 shows the error accumulation in RoI coordinates over a time of seven days, considering the angle between the CCD horizontal and solar Equator as 30 degrees. The coordinate values are updated every day, and hence we see the error coming down to zero after every 24 hours.

Figure 10
figure 10

Error accumulation is calculated for five different input-coordinate values (1100,1300), (900,1700), (700,2000), (900,2300) and (1100,2700) on the detector plane and plotted in blue, green, yellow, orange, and red, respectively. These coordinates correspond to different latitudes on the Sun disc. The calculation is done for a duration of seven days with coordinates updated every day.

Full size image

Figure 11 shows the RoI marked against the feature initially and after several hours. Cases 1 and 2 in Table 5 are shown in this figure. The red box indicates the RoI around the solar feature the algorithm is tracking. On the right are the images taken after several hours. It can be seen how the red box is still around the feature, which has moved considerably in this time. This is because the coordinates of the box (i.e. RoI) are updated regularly by the RoI tracking algorithm.

Figure 11
figure 11

Sample images to demonstrate the working of SUIT RoI tracking algorithm. The red box indicates the RoI size 704 × 704 pixels, whose center is tracked by the algorithm. We can see in the image on the right where the RoI still is able to track the active region.

Full size image
Table 5 Initial and final coordinate values tracked by the algorithm and the tracking time.
Full size table

4 Testing the Onboard Intelligence Modules in Hardware

The onboard-intelligence algorithm is implemented using an Actel RTAX 2000s FPGA. For ground testing, a prototyping adapter of an A3PE3000 FPGA is used. The coding is done in VHDL. In this section, the hardware-module testing using the laboratory setup is discussed.

4.1 HEL1OS Trigger Generation Module

A PC-based data and trigger simulator is made using a USB interface to simulate HEL1OS and SOLEXS interfaces for the ground-level testing. Input data are read from a user selected file and each data value from this file is sent to endpoint of USB controller. The input data are simulated using HEL1OS-like light curves (as explained in Section 3.1.2) corresponding to C-, M-, and X- class flares. The USB controller then sends the 32 bits of data to the SUIT electronics in a predefined serial interface once every second (equivalent to the cadence of HEL1OS data), thereby mimicking the HEL1OS interface. This simulator can also transmit two SOLEXS triggers, which will be discussed in a later section. The module is tested with combinations of different free parameters shown in Table 6. The Cases 1 and 2 correspond to true negatives, where the flare trigger is not generated because the Count Threshold and Flux Threshold conditions were not met, respectively. In the remaining cases, various combinations of Weights, Med Type, Skip Num, Count Threshold, and Flux Threshold are used for different input data. The trigger times are compared with those generated by running this data through the corresponding IDL code (refer to Section 3.1). The hardware module successfully generated the expected output in all the test cases.

Table 6 Various parameter combinations used to carry out hardware testing of HEL1OS flare-trigger module and the corresponding output. Cases 1 and 2 are true negative cases.
Full size table

4.2 Flare Localization Module with External Triggers and Self-Trigger

The flare-localization algorithm in SUIT will use four images of the Sun in Mg ii h binned by 2×2 pixels to localize the flare. In order to test this hardware module, a laboratory setup shown in Figure 12 is used. An LED is used as a source that simulates a flare-like condition. The current input to the LED is given through a Keithley source meter. The input-current profile of the source meter is derived from a flare-light-curve profile obtained from Mg ii h IRIS slit-jaw images. Since the input current to the LED follows the profile of a flare light curve, the output light intensity from LED also replicates it. The converging lens focuses the LED onto the CCD, and the recorded images will be used by the flare-localization module to detect the flare. One of the LED intensity profiles as recorded by the CCD is shown in Figure 13.

Figure 12
figure 12

The setup used to simulate the solar-flare intensity profile in the laboratory using an LED. The LED current is changed to simulate the flare-intensity profile.

Full size image
Figure 13
figure 13

The mean LED intensity profile as recorded on the CCD super pixel. The super pixel size taken is 32×32 pixels. The vertical line indicates the flare-localization time based on the image number.

Full size image

The flare-localization algorithm can be activated by an external trigger and also called internally during normal SUIT observations (self-trigger). Table 7 shows the threshold values used for Self-trigger and External-trigger modes.

Table 7 Threshold values used for laboratory testing of Self-Trigger and External-trigger flare-localization modules.
Full size table

4.2.1 Flare Localization Module with External Trigger

The flare-localization module is activated when there is an external trigger. As discussed in Section 1, along with the HEL1OS trigger, SUIT also gets triggers from the SOLEXS payload. SOLEXS gives two triggers using data from two different detectors. All three external triggers will be used to activate the flare-localization module. The objective of the test is two-fold. First, we test whether the flare-localization module is activated after an external-trigger is received, and second we test whether the flare-localization module, after activation, is able to correctly detect and localize the flare. For this testing, the flare data and trigger simulator module is used to generate these external triggers, and a flare light intensity is simulated using the LED setup explained in Figure 12. For the first part of the test, the two SOLEXS triggers and HEL1OS trigger are generated and the flare-localization module is activated successfully. Next, the detection and localization of the flare module are tested. Table 8 shows different cases that are used for this testing. These test cases individually test combinations of various conditions (thresholds Th1, Th2, and Th3, increase in intensity, position of max super-pixel, and flare position) that are required for the detection to be successful (as explained in Section 2.2). The flare-localization should not be successful if any one or more conditions are not satisfied (Cases 1 to 4), and if all conditions are successful, should produce the correct flare flag depending on the position of the flare. The Normal flare flag (NFF) and the Prominent flare flag (PFF) are produced depending on the position of the flare. NFF is produced if the flare is near the center, while PFF is produced if the flare is near the limb (Cases 5 and 6, respectively). In order to verify the flare-detection time and position obtained from the tests, the flare images used by the localization module are run through the corresponding IDL program (used in Section 3.2). The detection time is the image number after which the flare is localized, and the flare position is the set of RoI center coordinates produced by the module. The image number and the RoI coordinates are matched with those obtained from the IDL program for all test cases. In Figure 13, the red vertical line indicates the time (image number) at which the flare is detected and localized.

Table 8 Different scenarios that are tested on the flare-localization module.
Full size table

4.2.2 Flare Localization Module with Self Trigger

As part of the SUIT daily observation plan, Mg ii h full-frame images binned by 2×2 pixels will be recorded every minute and the flare-localization module is called. The flare-localization algorithm uses the latest image and previous three images. The algorithm used is same as that used for the external trigger, except that the image cadence in this case is lower and the thresholds used are higher (Table 7). For the testing, flare intensity is simulated using the LED as shown in the setup (Figure 12). The normal SUIT observation is carried out during this process. As explained previously, in this normal SUIT observation, a full-frame image binned by 2×2 pixels will be taken every minute and the flare-localization module is then called. The testing process is similar to that explained in Section 4.2.1. The detection time and location coordinates are compared with that obtained from the IDL program. Figure 14 shows a sample case, where a full-frame image of Sun with the LED before localization is shown on the left and the localized RoI image centered around the flare, selected by the flare-localization module, is shown on the right.

Figure 14
figure 14

The image on the left is a full frame binned image with the flare and the image on the right is the localized image of size 704×704 pixels. The localized image coordinates are obtained as (x1:670 , x2:1374) and (y1: 662 y2:1366).

Full size image

4.3 RoI Tracking Module

The RoI tracking module uses a pre-uploaded LUT to update the RoI coordinates at regular intervals. The LUT values depend on the angle between the Sun’s rotation axis and the CCD horizontal. To test the tracking, five different initial RoI coordinate values were chosen, and the tracking module generates the new RoI coordinates starting with the initial coordinates given. Every time the module was called (once every 30 minutes), it took the current RoI coordinates and used the LUT, to generate new coordinates, which were updated and used as the current RoI coordinates the next time.

The module is tested during the RoI observation mode. In this mode, RoI images were acquired continuously for a long duration, as specified. The initial RoI coordinates are fed in and are then updated every 30 minutes. So, as time progresses, the RoI image center gets shifted. Table 9 shows three different RoI cases used for testing along with the tracking duration and final coordinates generated after tracking. Figure 15 shows the initial image and the final image obtained after tracking for 14 hours (Case 1 in Table 9). The angle between CCD horizontal and solar Equator is taken as 30 degrees in this case shown. The shift in the RoI due to the algorithm is measured and it matches with theoretically calculated shift. For the first two cases shown in Table 9, the Sun center and the CCD center are aligned, while for the Case 3 they are different. The LUT remains the same for these cases. This exercise successfully tested the working of the RoI tracking module.

Figure 15
figure 15

These images correspond to Case 1 in Table 9. The image on the left is the initial image whose center is at (1927, 2085), and the image on the right is the final image with updated coordinates (1735, 2437). The overall shift is 192 pixels in X and 352 pixels in Y. The total tracking duration was 13 hours and 40 minutes.

Full size image
Table 9 Initial and final RoI coordinates during RoI tracking. Case 3 is a special case with the Sun center not aligned with the CCD center.
Full size table

4.4 Auto-Exposure Control Module

The automatic-exposure-control module is tested with the setup shown in Figure 12. The LED intensity is initially increased and then decreased in steps and an RoI containing the LED image is selected and observed. The automatic exposure control changes the exposure time depending on the LED intensity. From the RoI images, it is observed that, as the LED current increases, the intensity of the LED increases, decreasing the exposure time. Also, when the LED current is decreased, the intensity decreases and the exposure time increases correspondingly. Figure 16 clearly shows the effect of change in LED intensity on the exposure time. Table 10 shows the threshold values used in this module. Figure 17 shows the effect of automatic-exposure control on resultant images. The image on the left is over-exposed and few pixels (more than N1) are very bright (higher than threshold Th1). The automatic-exposure-control module reduces the exposure time of the next image. The image on the right is the resultant image obtained post-exposure change. The difference in the image contrast can be seen for same the LED intensity.

Figure 16
figure 16

Change in exposure time with respect to change in LED current. As LED current increases, LED flux increases and the exposure time is reduced and vice versa.

Full size image
Figure 17
figure 17

Images to demonstrate the effect of the automatic-exposure control. The image on the left contains near-saturated pixels, which influences the automatic-exposure module to reduce the exposure time. The image on the right is taken with reduced exposure time (and same input light intensity) and shows a better contrast.

Full size image
Table 10 Threshold values used for the automatic exposure control. The exposure time is decreased when more than 1024 pixels have a value more than 24,000. The exposure time is increased when less than 1024 pixels have value more than 14,000.
Full size table

5 Summary and Conclusions

In this work, a novel onboard-intelligence algorithm for flare studies is developed and tested successfully. The algorithm is simple yet elegant, balancing efficiency and implementation complexity. The intelligence algorithm helps in reducing the load on data telemetry and at the same time increasing the data cadence and hence providing better scientific outcome. Since the flare-observation mode is of the highest priority and is done onboard, SUIT is expected to observe a large number of flares from the initial stage of their evolution. The algorithm is tested using SDO/AIA 1600 Å images, IRIS Mg ii h slit-jaw images, GOES soft X-ray light-curve data, and RHESSI hard X-ray light-curve data. The algorithm tests gave the expected results in generating hard X-ray flare triggers, detecting and localizing the flare using UV images, tracking a region of interest on the solar disc over long duration, and automatically changing the exposure time based on the images. The algorithm is also implemented in an FPGA within the given limitations. We also tested the FPGA hardware using a setup in the laboratory that simulates a real-time scenario in space. The HEL1OS flare-trigger module is able to detect the flares with 100 percent efficiency and with an average detection time of 180 seconds from GOES catalog start time. The flare-localization algorithm is able to successfully localize all 49 flares from AIA 1600 Å images. The average localization time from IRIS Mg ii h images is under 30 seconds from GOES start time. The RoI tracking algorithm is able to track the RoI coordinates for a duration of over 200 hours with maximum error of under 80 pixels. The automatic-exposure-control algorithm is able to control the exposure and prevent saturation of pixels during the peak of the flare. These results prove the efficiency of the onboard-intelligence algorithm and successfully demonstrates their capability.

Although the algorithm is highly efficient, we would like to point out a few limitations. The efficiency of the algorithm depends strongly on the threshold parameters set. These parameters will be updated continuously during the post-launch calibration. We might initially miss a few flares and also get few false triggers in this phase. The efficiency keeps improving as we get more and more data. Also, the flare-localization module is designed to detect only one flare at a time. When there are multiple flares happening at a time, the module can detect only one flare that satisfies the algorithm conditions first. In the event of two or more similar flares happening simultaneously, the algorithm might be confused and may not be able to detect any flare. However, this is a very rare scenario. The RoI tracking module uses an approximate value corresponding to the rate of change in position of an RoI on the solar disc. Although the values might differ from the original values by a few pixels, this will be a negligible change as compared to the size of RoI. Just as in the case of flare-localization module, the auto-exposure module efficiency is also highly dependent on the threshold values that are chosen. There might be a possibility where the exposure time could continuously toggle if these values are not defined properly. In spite of these few drawbacks, this onboard-intelligence algorithm is very efficient in making several decisions onboard without any external intervention. This allows us to obtain very high cadence data of flares from their early stage of evolution. This makes SUIT a one-of-a-kind payload and it is expected to provide excellent NUV solar-flare data post launch.