Fault Injection by Simulation

This book exposes the reasons behind the concerns surroimding a system s fault tolerance. Some of the most irrrportarrt farrlt tolerance techniques presented in the literature are analyzed arrd three novel hybrid techniques to detect farrlts in processors are presented in detail. It also covers fault injection techniques appUed to the novel techrriques, including farrlt injection by simrrlation, configuration bitstream farrlt injection, and neutron arrd Cobalt-60 beams irradiation experimerrts. 

Azambuja et al.. Hybrid Faith Tolerance Techniques to Detect Transient Faults in Embedded Processors, DOI 10.1007/978-3-319-06340-9 l, 

In order to provide reliable systems that can cope with radiation effects, we believe that the solution hes in combining software-based and hardware-based techniques. The main objective of this book is finding the best trade-off between software-based and hardware-based techniques, in order to increase existing fault detection rates up to 100%, while maintaining low overheads in performance by means of operating clock frequency and application execution time, and in area by means of program and data memory overhead, and extra hardware modules. 

In the next step, we will cormnent on some of the state-of-the-art hteratnre for fanlt tolerance techniqnes nsing hardware-based techniqnes, software-based techniqnes and hybrid ones, as well as the main reasons for not existing available techniqnes that can fully protect a processor against transient effects without expensive drawbacks in performance degradation or area overhead. 

Following the state-of-the-art review, the next step is to implement fault tolerance techniques. We will start by explaining in detail and implementing two known software-based techniques, called Variables and Inverted Branches (AZAMBUJA 2010b), which will later be used as a complement to hybrid fault tolerance techniques. These techniques have been proposed in the past years and achieved high fault detection rates at low performance degradation levels and therefore are useful not only as an introduction to software-based fault tolerance techniques, but also to be combined with hardware-based and hybrid techniques. Then, three novel hybrid techniques will be proposed and implemented, based on both software and hardware replication characteristics. The three hybrid techniques will be divided into their software and hardware sides and described in detail, concerning both operation description and implementation. 

---

Table 5.3 Number of faults injected by simulation fault injection in miniMIPS protected by OCFCM and the percentage of detected errors 67...

Although the effect of faults is increasing, the rate is not yet sufficient to test fault tolerant techniques at ground level. In order to do so, fault emulation and testing is necessary. In this Section, we will go over a few options to do so, such a software fault injection by simulation, fault injection in the FPGA s memory configuration bitstream and irradiation experiments. 

Fault injection by simulation can be done by injecting faults at logical or electrical levels in conunercial simulators, such as ModelSim from Mentor or iSim... 

As mentioned in the previous Chapters, fault injection campaigns can be performed in different levels. The fault injection by simulation is performed by adding upsets when simulating a given system in commercial simulators, such as ModelSim from Mentor or iSim from Xilinx, or open source simulators, such as Spice. They are able to provide the best control over the experiment. This characteristic is because the simulation can be stopped at any simulation time and the internal values from anywhere inside the system can be read and stored for post-analysis. As a consequence, the amount of data is the biggest among the different levels of available fault injection campaigns types. 

As a drawback, fault injection by simulation requires considerable computational power and simulation time, since huge amounts of data must be processed, relative to the size of the circuit and its complexity. As an example, the injection of 100,000 faults in the mimMlPS may take up to a few days to finish, depending on the simulator and the application running on the processor. 

This fault injection campaign simulates the effects of transient farrlts in the case-study system is implemented in a Flash-based FPGA, the ProASIC3 from Actel, where the user s logic (VersaTiles) can be upset by SEU and SET. 

Soft errors can be detected and corrected by the system s logic, meaning that it does not require a hard reset to recover from an error. Sections 7.1.2 and 7.2.2 present neutron irradiation experiments simulating the effect of SEE in Flash-base and SRAM-based FPGAs, while Chaps. 5 and 6 present fault injection simulation experiments simulating SEEs at RTL level and in the configuration memoiy bitstream, respectively. In this work, SEUs and SETs will be used to describe transient faults that the proposed techniques can cope with. 

In order to perform the fault injection campaign by simulation and test the fault tolerant techniques from Chap. 4, we used the fault injector proposed and described in Azambuja (2010b), which uses the commercial simulator ModelSim. The main reasons for using this fault injector were accessibility to its source code and the possibility to automate the process that could take up to weeks of computatiom... 

The experiment eontinuously compared the PC of a golden miniMIPS with the PC of the faulty one. Fault injection results are presented in Table 5.3. It shows the number of iqected faults (Faults Injected) for each application, the number of faults that caused an error to the microprocessor (Incorrect Result) and the detection rate achieved by the proposed solution (Errors Detected). The system was simulated with a clock period of 42 ns and a total of 2459 signals describing it. Forty thousand faults represent 16 times the number of signals, but only 0.4 % of the extensive pos-sibihties of faults for the encryption algorithm... 

Firstly, the models basic simulation environment is introduced. It is the starting point for the application of the fault injection platform. Secondly, elements of the fault injection platform are introduced into this basic environment. To implement this work, UML 2.0 is applied by the support of Rhapsody Designer Tool platform. 

Hence, robustness of the communication protocol among microprocessors and the implication of this protocol vulnerability on the global behaviour are dynamically checked by simulation. Figure 6 shows a sequence diagram of data interchanged between processors (two in this particular case) when they work without fault injection and when a fault is injected. 

Analysis of fault effects requires detailed information on the faults injected and the application behaviour. FITS provides details about every test (simulated fault injection). Hence, manual replay of the whole test execution can be done. Moreover, all the events and user messages occurring during the test are recorded. The tested application is instrumented to save its outputs (here simulation results, i.e. a set of process signals (u u, y y ) in subsequent sampling instants) into separate files for each test (file names managed by fault injectors). This gives a possibility for post-experiment analysis of fault effects in the correlation with the injected fault and observed behaviour for each test (see Sect. 5). 

Fault tolerant design for reliability is one of the most difficult tasks to verify, evaluate, and validate. It is either time-consuming or very costly. This requires creating a number of models. Fault injection is an effective method to validate fault tolerant mechanisms. Also an amount of modeling is necessary for error/fault environment and structure and behavior of the design, etc. It is then necessary to determine how well the fault tolerant mechanisms work by analytic studies and fault simulations [7]. The results from these models after analyses shall include but not be limited to error rate, fault rate, latency, etc. Some of the better known tools are HARP—hybrid automated reliability predictor (Duke), SAVE—system availability estimator (IBM), and SHARPE—symbolic hierarchical automated reliability and performance evaluator (Duke). 

The proposed scheme is implemented in Simulink where V-Rep is used as for simulating the environment. We obtain reproducible results and are able to analyse the effect of observation failures on the performance of the system. By using a fault injection framework, we compare test cases with and without failures. In accordance to the injected failure amplitude, the car degraded its performance in order to comply with requirements. It should be noted that the system stops if the car is not able to keep within the lane due to injected failures or limitations of the steering angle. 

The objective of fault injection is to introduce artificial fault or errors in a system to test the system in presence of errors. The injection of faults using MODIFI is done by rerouting the connection between blocks in the model to also include a fault model. This is illustrated in Fig. 1 and Fig. 2, which show a Simulink model before and after MODIFI has inserted a fault injection block. The fault injection block will pass the input value to the output port unmodified unless a trigger is enabled. The trigger, which is based on the simulation time, will cause the block to apply the fault model, a bit-flip in this case, to the output. Fig. 2 also shows that MODIFI turns signals in the model into Simulink test points [10] which all have logging enabled. 

In the traditional fault diagnosis of circuits based on BP neural network, voltage data of key points which can be obviously affected by faults is usually taken as input information of the network. Generally, the output of the net is the codes of failure modes. After the data samples obtained from the simulation or fault injection experiments, training and testing can be carried out (Ma et al. 2013). 

The paper is structured as follows Section 2 briefly describes previous related work. Section 3 reviews the PS-TTM modeling and simulation platform for dependable time-triggered embedded systems, which is the platform where the testing and fault injection framework has been developed. Section 4 presents the framework for the verification of time-triggered dependable systems by simulated fault injection at different stages of the development, which is evaluated in Section 5 by means of a case study based on a simplified railway signaling system. Section 6 briefly presents the results obtained in the case study and finally Section 7 summarizes the main conclusions of the work. 

In order to check the testing and simulated fault injection fi amework described in Section 4, we model a simphfied railway signaling system by means of the PS-TTM platform. Following the approach described in the PS-TTM, we first design a PIM and we later refine it into a PSM. 

This section describes the reliability assessment made to the railway signaling system model described in Section 5. The fault-tolerance provided by the system is evaluated by means of simulated fault injection. To do so, the PS-TTM ATE framework described in Section 4 is connected to the SUT and the environment model as shown in Fig. 4. 

Regarding the estimation of the speed, the experiments made by means our fault injection framework show the robustness of the algorithm. In this case we also get the maximum error in the 8 campaign, where at instant 151.75s we find a disagreement of 1.350m/s respect to the non-faulty simulation (60.23m/s, 2.24%). ... 

As the table shows, all the faults injected in the system during the simulations were detected by the voters. Since we configured all jobs in the system with a period of one macrotick (250ms), corruption and babbling faults were detected 250ms after their injection in the system, as expected. Bit-flips in signals and open circuits were also detected in the next macrotick. 

All in all, the faults were detected as expected. The voters also notified a multiple failure caused by the two faults injected in the system during the S simulation. That occurred at instant 150.25s, and also caused the activation of the emergency brakes of the train, as stated by the requirements. Fig. 6 shows an extract of the results of the the 5 simulation. For the sake of simplicity, we omit input signals of emergency and service brakes from the figure. 

The Automatic Test Executor (ATE) presented in this paper is composed by three different modules for the design and simulation of test-cases, injection of faults during simulation and storage of simulation results for the evaluation of the behavior of the system under such faults. The ATE is synchronized with the simulation time of the SUT, a way that functional tests and fault injection experiments become reproducible. 

---