Experience with fault injection experiments for FMEA

Authors:
Lars Grunske;Kirsten Winter;Nisansala Yatapanage;Saad Zafar;Peter A. Lindsay
Affiliations:
Swinburne University of Technology, Faculty of ICT, Hawthorn, VIC 3122, Australia;School of ITEE, The University of Queensland, St. Lucia, QLD 4072, Australia;Software Quality Institute, Griffith University, Nathan, QLD 4111, Australia;(Was at Griffith University when working on this project.) Riphah International University, Rawalpindi, Pakistan;School of ITEE, The University of Queensland, St. Lucia, QLD 4072, Australia
Venue:
Software—Practice & Experience
Year:
2011

Citing 0
Cited 3

Execution of natural language requirements using State Machines synthesised from Behavior Trees

Journal of Systems and Software
Identifying hardware failures systematically

SBMF'12 Proceedings of the 15th Brazilian conference on Formal Methods: foundations and applications
Visual-trace simulation of concurrent finite-state machines for validation and model-checking of complex behaviour

SIMPAR'12 Proceedings of the Third international conference on Simulation, Modeling, and Programming for Autonomous Robots

Quantified Score

Hi-index	0.00

Visualization

Abstract

Failure Modes and Effects Analysis (FMEA) is a widely used system and software safety analysis technique that systematically identifies failure modes of system components and explores whether these failure modes might lead to potential hazards. In practice, FMEA is typically a labor-intensive team-based exercise, with little tool support. This article presents our experience with automating parts of the FMEA process, using a model checker to automate the search for system-level consequences of component failures. The idea is to inject runtime faults into a model based on the system specification and check if the resulting model violates safety requirements, specified as temporal logical formulas. This enables the safety engineer to identify if a component failure, or combination of multiple failures, can lead to a specified hazard condition. If so, the model checker produces an example of the events leading up to the hazard occurrence which the analyst can use to identify the relevant failure propagation pathways and co-effectors. The process is applied on three medium-sized case studies modeled with Behavior Trees. Performance metrics for SAL model checking are presented. Copyright © 2011 John Wiley & Sons, Ltd.