Model-driven automated software FMEA

This paper describes how software FMEA can be automated both for low-level languages intended for safety critical embedded systems, and also for model-driven software developments. It is possible for a computer to achieve a qualitative analysis of software based on tracing dependencies through a body of code. This can reveal the propagation of any failure in the software, whatever the cause of the failure. Application of a higher level representation of the intended purpose of the software can then automatically interpret the implications of failure in terms of the requirements put on the software. These techniques have been used to automate the analysis of several thousand lines of code. They have been shown to provide useful results for software engineers, and would suit embedded software in vehicles for example. This work is not a cure-all for badly written software, but provides assistance in software analysis for well designed systems in low-level "safe" languages such as MISRA C. The software FMEA can be used to improve automated or source code embedded testing since tests can exonerate many potential faults allowing the FMEA analysis to present an engineer with a reduced set of potential faults. Model-driven development (MDD) is a software development philosophy which encourages the development of models of the software to be produced, for example using a language such as executable UML. The system is described in a platform independent manner, and then the software to be used is automatically generated from the model. In MDD, the models make the intentions of the programmer much more explicit than is the case for low-level programming, and so the gap between the intended functions of the system and the description of the software is not so large. Representation of the design is much more explicit through use cases, component diagrams, state charts and sequence diagrams. All of this design information can be utilized for the automated generation of software F MEA. This means that FMEA for model-driven software can be done more easily than for a system implemented in a low-level language, because it is not necessary to attempt to reconstruct the intentions of the programmer from the functions of the system and the low-level code. The paper also discusses the advantages and dangers of doing such analysis at the design rather than the code level.