Generation of an error set that emulates software faults based on field data

Christmansson, J.; Chillarege, Ram

doi:10.1109/ftcs.1996.534615

Cited by 106 publications

(87 citation statements)

References 14 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…We injected bugs from the five types in Table 2 source code of the drivers. Empirical evidence indicates that these types of bugs are common in operating systems [8,40]. The random increment to loop upper bounds and to the number of bytes copied was 8 with 50% probability, 8 to 1K with 44% probability and 1K to 2K with 6% probability.…”

Section: Effectivenessmentioning

confidence: 99%

Fast byte-granularity software fault isolation

Castro

Costa

Martin

et al. 2009

Proceedings of the ACM SIGOPS 22nd Symposium on Operating Systems Principles

134

View full text Add to dashboard Cite

Bugs in kernel extensions remain one of the main causes of poor operating system reliability despite proposed techniques that isolate extensions in separate protection domains to contain faults. We believe that previous fault isolation techniques are not widely used because they cannot isolate existing kernel extensions with low overhead on standard hardware. This is a hard problem because these extensions communicate with the kernel using a complex interface and they communicate frequently. We present BGI (Byte-Granularity Isolation), a new software fault isolation technique that addresses this problem. BGI uses efficient byte-granularity memory protection to isolate kernel extensions in separate protection domains that share the same address space. BGI ensures type safety for kernel objects and it can detect common types of errors inside domains. Our results show that BGI is practical: it can isolate Windows drivers without requiring changes to the source code and it introduces a CPU overhead between 0 and 16%. BGI can also find bugs during driver testing. We found 28 new bugs in widely used Windows drivers.

show abstract

Section: Effectivenessmentioning

confidence: 99%

Fast byte-granularity software fault isolation

Castro

Costa

Martin

et al. 2009

Proceedings of the ACM SIGOPS 22nd Symposium on Operating Systems Principles

134

View full text Add to dashboard Cite

show abstract

“…The main elements that characterize FI (experiments, or campaign) are: the set of faults to be injected (the Fault model), the system activities under which the faults are injected (the Activation), the Readouts of the experiment results, and the Measures evaluated, based on the readouts. These elements form the basis of the FARM [5] method to FI, similarly to other existing FI methods (see e.g., [6]). It is worth to mention that the measures, M, are defined first, since they guide the whole FI process, but their values are assessed in the last step, by processing information provided by the readouts.…”

Section: System Development Processmentioning

confidence: 99%

From Safety Analyses to Experimental Validation of Automotive Embedded Systems

Pintard

Fabre

Leeman

et al. 2014

2014 IEEE 20th Pacific Rim International Symposium on Dependable Computing

View full text Add to dashboard Cite

Abstract-Automotive embedded systems are becoming increasingly complex. Therefore verification activities are paramount to ensure safety. ISO 26262 is the first standard specifically dedicated to automotive safety systems. This standard requires introducing fault injection (FI) from the very early phases of the development process. Our work aims at developing an approach that will help integrate FI in the whole development process in a continuous way, from system requirements to the verification and validation phase. In this paper, we concentrate on exploring the benefits of safety analyses for experimental validation of the system. We propose an analogy between FI during the pre-implementation phase with safety analyses that are of common use during system design. We finally illustrate this approach on a case study from the automotive domain.

show abstract

“…For an extensive overview of mutation-based testing and fault models, the reader should refer to [16]. More studies about the various aspects of software fault injection and fault models can be found in [12,13,17,24].…”

Section: Software Fmeamentioning

confidence: 99%

Model Checking-based Software-FMEA: Assessment of Fault Tolerance and Error Detection Mechanisms

Molnár

Majzik

2017

Period. Polytech. Elec. Eng. Comp. Sci.

View full text Add to dashboard Cite

Failure Mode and Effects Analysis (FMEA) is a systematic IntroductionThe risk of failure is one of the main concerns of safetycritical systems. Certification requires the systematic analysis of potential failures, their causes and effects, and the evaluation of risk mitigation techniques used to reduce the chance and the severity of system-level failures.One of the first systematic techniques for failure analysis was Failure Mode and Effect Analysis (FMEA) [2]. FMEA is often the first step in reliability analysis, as it collects the potential failure modes of subsystems, their root causes and their effects on the whole system. Together with criticality analysis (often treated as part of FMEA, sometimes emphasized by the term FMECA), the output of FMEA serves as the basis of other qualitative and quantitative analyses, as well as design decisions regarding risk mitigation techniques.FMEA is usually applied at the hardware and communication level, where it requires a qualified analyst to collect postulated component failures and identify their effects on other components and the system level. In case of software (SW-FMEA), failure modes originate in different types of programming faults, commonly referred to as bugs. Due to the complex nature of software and the many types of potential bugs, it is much harder to collect failure modes and deduce their potential effects, so an automated mechanism is desired. This paper presents a way of automated SW-FMEA with the use of executable software models. Assuming a set of predefined fault types (programming faults) and a specification of safe behavior at the system level, the proposed approach applies model checking to systematically generate execution traces leading from fault activations to states that violate the specification of safe behavior (system-level failures). These traces can be used to understand and demonstrate fault propagation through the system and also as test sequences to reveal actual faults in the final product.Our approach improves existing model checking-based SW-FMEA by optimizing fault activations and using monitor components instead of a formal specification. The optimization helps in scaling the solution to apply it on more complex systems and situations, whereas using a monitor instead of formal

show abstract

Generation of an error set that emulates software faults based on field data

Cited by 106 publications

References 14 publications

Fast byte-granularity software fault isolation

Fast byte-granularity software fault isolation

From Safety Analyses to Experimental Validation of Automotive Embedded Systems

Model Checking-based Software-FMEA: Assessment of Fault Tolerance and Error Detection Mechanisms

Contact Info

Product

Resources

About