Non-intrusive Fault Injection Techniques for Efficient Soft Error Vulnerability Analysis

Abstract

Sistemas eletrônicos estão integrando processadores multicore e GPUs (Graphical Processing Unit) com o objetivo de executar configurações complexas de aplicações. É esperado que esses sistemas sofram com pelo menos uma falha por dia nos próximos anos, o que pode levar a erros que coloquem a vida de outros em perigo. Esse trabalho apresenta quatro novas técnicas de injeção de falhas que possibilitam um maior controle e analise do comportamento de sistemas multicore. Essas técnicas são não intrusivas, isto é, não precisamos modificar o software ou o hardware, e são integradas em um framework para execução automática. Para validá-las, nos utilizamos aplicações reais com ate 43 bilhões de instruções. Resultados inicias mostram que isolar partes criticas de uma aplicação pode levar a uma analise de soft-error mais eficiente, ou seja, reduzir o numero de falhas mascaradas em até 28%. Falhas mascaradas não proveem informação sobre o que aconteceria com o sistema, mas sim a probabilidade de um erro ocorrer.

An Extensive Soft Error Reliability Analysis of a Real Autonomous Vehicle Software Stack

“…In contrary, this paper evaluates the same algorithm but isolating its main functions while considering different images, compilers and processor architectures under 210 fault injection campaigns. The Darknet + YOLO algorithm is also used in [3] to validate new fault injection techniques. In this work, we gathered the soft error reliability of Darknet + YOLO algorithm considering only one input image, the Clang compiler and an ARMv7 processor architecture.…”

“…Rather than developing a fault injection (FI) framework from scratch, we evaluated the performance of two opensource FI approaches [7], [3] when executing the target automotive benchmark. Due to the complexity of the underlying benchmark (i.e., up to 104 billions of instructions executed), conducting the soft error evaluation using the gem5-based FI framework [7] would restrict the number of explorations.…”

“…Due to the complexity of the underlying benchmark (i.e., up to 104 billions of instructions executed), conducting the soft error evaluation using the gem5-based FI framework [7] would restrict the number of explorations. While a single execution of the Darknet benchmark can take up to 12 hours with the gem5-based approach [7], SOFIA [3] requires less than twenty minutes to execute the same scenario. SOFIA also offers a set of FI techniques that enable bespoke inspections targeting a specific critical application, operating system or API structure/function.…”

“…After some experiments, we identified that Cho's classification falls short when it comes to defining object detection algorithms, which produce outcomes based on probabilities, not on just absolute "yes" or "no". For this reason, this work also adopts the classification proposed in [3], which includes the following conditions: correct output when the outputs (golden and FI) match, i.e., masked fault; incorrect if at least one object or probability is different. Further, the incorrect result can be split into incorrect probability when all objects are correct, but at least one has a different percentile of confidence-in most cases this would not influence the action of an autonomous vehicle; wrong detection, i.e., false positive or missing of an object; and no prediction, if no object is in the image.…”

“…Due to the complexity of such stacks (e.g., kernels, drivers and heavy applications), analysing their soft error reliability may take several months if conducted at low level simulations (e.g., gate-level). For this reason, this work utilises an open-source fault injection framework [3] to perform an in-depth and extensive soft error susceptibility evaluation of a realistic automotive software stack. Different from other works, this paper contributes with an extensive soft error assessment that employs a technique that isolates the critical functions of a real automotive application while considering different inputs (e.g., images), kernels, compilers and processor architectures.…”