## 4 Discussion  
In this article, we described a platform dedicated to nano-satellite system including fault mitigation mechanisms to deal with SEU due to space radiation, and dynamic reconfiguration capabilities to adapt itself to the level of these radiations. The proposed platform offers a balance between performance and safety when running computationally intensive applications such as post-quantum cryptography. The computation part of the application is deployed on TMR partitions designed to support the mode switching in a flexible way. This flexibility has a cost in term of hardware resources. It puts pressure on the place and route process but it permits embedding a smaller device, thus a cheaper device, in the nano-satellite payload board without sacrificing functionality. In addition, a smaller device implies a lower power consumption. In order to make the Low-Power mode more interesting, it would be useful to apply software procedures like adjusting the energy-saving settings of the processor when idle to improve the overall system power consumption. Figure 8 also shows that switching from High-Performance mode to Safe mode, and vice  
Figure 9: System reliability at 100 ms injection period. versa, is not detrimental. It means that no extra power budget would be required in case a mode is run more than the other. Regarding the system reliability, the proposed platform provides an architecture that allows performing early tests of the fault mitigation mechanisms. In our case, fault injection during testbenches has been performed at a period of 100 ms. This period is very pessimistic and has been chosen to speed up the test runs. In real cases, fault occurrence is far more less important. In [19], SEU count per day at 705 km altitude was measured between 170 to 255, with an occasional peak at 1188. Another measure in a Low Earth Orbit of 686 km indicates an average SEU count per day of 100 [20]. We can also notice that using a 16 nm process, Ultrascale+ devices are less sensitive to radiation than previous FPGA generations. This better robustness does not mean that the switch from the High-Performance mode to the Safe mode can be performed at any time. Regarding the radiation level measured by the SEM Controller, if this level is low, the reconfiguration can be done safely. Otherwise, additional mitigation measures must be taken such as checking the reconfigured partition using the DPR to perform a readback of the configuration memory. When in Safe mode, the choice has been made to not dynamically reconfigure the two filters using the DPR, and to keep the AES IP in place. This choice has been made because, in this case, with the board being assaulted by radiation, it would have been hazardous to perform a dynamic reconfiguration of the FPGA. When in High-Performance mode, regarding the radiation level measured by the SEM, adding new functionalities to the platform and performing a check of the dynamically reconfigured IP could be considered. The system reliability measurement of these different configurations has been depicted in Figure 9. It shows that the High-Performance mode using the scruber only improves the reliability by x4, whereas the Safe mode, in which the TMR feature is added, improves this reliability by x4.4. In future work, solutions to enhance platform reliability will be explored. These solutions include features such as repeats of computation failure [21]. Instead of considering that the system has failed and that we need to reboot it, we allow time for the scruber to perform another round of checking. If, after this round, the fault is still present, we perform a safe recovery of the system. With regards to the fault injection period, it has been setup to keep the same injection scheme for every test run (one fault every 100 ms). For a more realistic simulation, a random distribution of the fault injection will be used in the future platform.