Resultados de los proyectos de investigación

6.1.2 Fault Injection Characterization of the Tool ... 97 6.2 WdgM Implementations Assessment ... 98 6.2.1 Error Detection and Error Recovery Coverage ... 98 6.2.2 Timing Evaluation of the WdgM... 99 6.2.3 Robustness of the implementation of the WdgM ... 100 6.3 Front-Light Software Verification ... 103 6.3.1 Verification of one Line of FMECA: S-Shaped Verification ... 103 6.3.2 Global Verification of the FMECA Spreadsheet ... 104 6.4 Conclusion ... 105

6.1 Fault Injection Platform

A fault injection tool has been developed at Valeo, in order to implement the FI campaigns designs from the safety analyses. We mainly focus on the integration of two techniques: Software- Implemented Fault Injection (SWIFI) and Nexus-Based Fault Injection. These two methods have been introduced in Chapter 1.

6.1.1 Fault Injection Environment

Figure 6.1 shows an overview of the FI Environment

FIGURE 6.1FAULT INJECTION ENVIRONMENT

This environment encompasses:

 The Target System is composed of the Front-Light Manager application (binary files

ELF compiled from sources with Wind River Compiler) running on the SPC56EL70

microcontroller described before.

 The Controller is composed of the interface of the debugger Lauterbach TRACE 32. It

enables fault injection experiments via scripts (PRACTICE Language). It also captures the execution trace of the target, controls the access to the memory for monitoring some variables, and provides commands to start the fault injection test cases according to a specified workload.

 The Lauterbach debugger (Lauterbach, 2015) is a central component of the

Environment. It is connected to the controller via a USB link and to the target throughout a Nexus Probe. The debugger provides access to all memory sections of the microcontroller, particularly by monitoring the trace of the execution of the application (Monitor). Data Collector Data Analyzer FI Tests Logs

ECU external

fault injection

ECU internal

fault injection

+

NEXUS / JTAG Adapter

Debugger Interface (Trace 32) USB Microcontroller SPC 56EL70 Application Binary files FI Tests Logs FI Tests Logs Application Source files_{Source files}Application Application

Source files Application Source files FI Specific modification _Workload library Funct. Req. & Behavioral models Fault library Safety Analyses (FMECA, FTA…) Measures Manual Compiler

Wind River Flashing

FI Tests Logs FI Tests Logs FI Tests Scripts

Fault injector, Monitor and Workload generator

Controller

 The Lauterbach debugger is also a Fault Injector, as it allows corrupting/modifying memory locations of the application. These capabilities are provided by the

implementation of Nexus Class 3+ defined by the Nexus 5001 ForumTM _(Nexus5001,

2015). This class of debugger enables two important features to perform read/write into the memory without any impact on the real-time execution of the application. This “On- the-fly” runtime memory access does not add temporal overhead. Moreover, the debugger also takes advantages of on-chip watch points (a watch point enables the activation of the fault injection experiments to be triggered or signaling application events without stopping the application). Finally, the debugger enables monitoring the behavior of the execution of the Software through the memory to collect observation data (readouts) and to synchronize the activation of the experiments (Workload Generator), and finally, modifying the memory to inject fault in memory, registers, etc. (Fault Injector)

 We also use SWIFI method to inject specific fault/error/failure. Hence, we instrument

the code to mimic the faulty behavior directly by modifying the source code of the faulty software module, and finaly compiling the mutant application.

 The Data Collector stores the data collected during the experiments into log files. The-

se are timing information, variables values and events.

 The Data Analyzer in our environment is mostly manual. The data is gathered automat-

ically in the logs, however the analysis of the results has to be done manually, e.g., the categorization of the experiments.

6.1.2 Fault Injection Characterization of the Tool

We present the characterization of the fault injection techniques integrated in tool by considering the following properties, defined in (Arlat, et al., 2003):

 Reachability: Using both pre-runtime SWIFI and Nexus-based fault injection, we are

able to manage a high level of reachability. Indeed, we are able to inject fault directly in the memory, the CPU registers using the debugger. It is also possible using SWIFI to corrupt higher levels of granularity, by injecting information explicitely processed by the computing system.

 Controllability, with respect to space and time: The controllability is also high as the fault can be triggered using low-level mechanisms from the debuggers (break and watch points in the program flow, writing/reading access to specific data). It may also be used together with SWIFI, for instance to trigger a branch of instrumented code.

 Repeatability (with respect to experiments) and Reproductibility (with respect to

results): A high repeatability is attained thanks to the high level of controllability. However, a distributed architecture with complex environment (multiple ECU on the network) may be more difficult to synchronize and thus, it would be more difficult to ensure repeadability in this case. In our case the microcontroller behavior allows a high repeatability

 Non-intrusiveness: The intrusiveness of the Nexus capabilities is very low. The

intrusion can also be related to the use of watch points, but there are few “real-time” watch points in practice. In addition considering the SWIFI, it is clear that the intrusiveness depends on the size of the corruption made in the source code. In our case, this second type of intrusion is negligible. Then, the use of SWIFI does not modify the behaviour or the structure of the safety mechanisms. Otherwise, the experiment results may be biased.

 Time measurement (e.g., error detection latency): Here, time measurements are

performed by the debugger. It is possible to get the execution time between two events.

 Efficacy to generate significant experiments: Generally, this property aims at

characterizing a fault injection technique together with a fault model. In our approach, the efficacy is based on the identification of the tests cases, more precisely the selection of the fault to be injected.

To conclude, the tool enables handling most of the Fault Injection experiments on any target application running on any micro-controller.