## 3 Test Environment for TMR Mitigation Structures
In the most elementary case, the individual registers can be triplicated as in Figure 9a. However, it must be remembered that the voter is then built into each set of registers. Although this kind of protection seems best, the disadvantage is the overhead resulting from the use of multiple voters. Therefore, in practical applications, triple modular redundancy is considered for the entire module performing a specific function, as shown in Figure 9b. This approach leads to a significant reduction in the number of voters required. However, the question remains open as to how to test such a circuit, or more precisely, where to inject the errors. Well, attaching an error injector to the output of a module performing a specific function will have a different purpose than attaching an error injector to the input of such a circuit. In the former, it will be possible to analyse SEU-type error  
\[SW_{i}=2P(x)(1-P(x)) \tag{2}\]1 Micro-architecture of the error injector module for buses. corrections, and in the latter also SEFI-type errors. This is because a change in the input state in the module can lead to a malfunction of this circuit (for example, the sequential automaton will go to the wrong state). At the same time, the individual modules of a given block subject to TMR may have different numbers of input and output ports. The error injector circuit will then be attached to each input and output, as shown in \[SW_{i}=2P(x)(1-P(x)) \tag{2}\]2  
The hardware-test environment with fault injection blocks shown in Figure 10 demonstrates the need for a flexible approach to testing. The FNCT block contains three modules (MODULE A, B and C). Each has a slightly different configu  
\[SW_{i}=2P(x)(1-P(x)) \tag{2}\]3 Triple modular redundancy system applied to modules performing a specific function. \[SW_{i}=2P(x)(1-P(x)) \tag{2}\]4 Triple modular redundancy system: applied to registers (**a**) and applied to modules performing a specific function (**b**). ports: MODULE A has one input and two output ports, MODULE B has two input and one output and MODULE C has one input and one output. In the general case, the ports are multibit and the use of an error injector as in Figure 8 is appropriate here, with the injector module shown here broken down into three FNCT blocks. For example, MODULE A IN ERR_INJ at the input of MODULE A in FNCT block #0, FNCT #1 and FNCT #2 are one and the same injector enabling the generation of errors at the inputs of the individual modules. Of course, testing the correctness of the mitigation in the TMR circuit shown in Figure 10 only makes sense for injecting errors into one channel, i.e., into one of the three inputs. Secondly, as errors are injected at the input of a given module, errors are not injected at their output, in line with the very idea of TMR, which says that two misrepresentations are not corrected. In contrast, the testing of MODULE A, MODULE B and MODULE C can be carried out in parallel if there is no data flow between these modules, i.e., they perform functions independent of each other. The error injector proposed by the authors was used in a mitigation study of the Quasar project carried out by KP Labs for the ESA (European Space Agency) [47]. This shows that the proposed solutions are scalable. This project uses an AMD Kintex Ultra-Sacle+ FPGA device (XCKU035-2 SFVA784I). The use of a device with such significant resources is necessary due to the need to implement a complex design (a radio channel for telemetry modules, telecommand, encryption, etc.). In general, in space missions, the implemented designs are most often so large that it is necessary to use FPGA devices with significant logical resources. Naturally, a TMR-based mitigation process is therefore often used for large-scale projects. The experimental section presents the results of mitigation in this project.