If your system is safety critical, and your hardware is getting  the FMEA treatment, you have better treat your software as not less critical. As in the case of hardware, a software FMEA is an incredibly valuable addition to the organizational knowledge base. Every additional program FMEA will reduce future FMEA efforts and will also provide the basis for safer and more cost effective design and coding in the future. As in hardware, the software FMEA shows:

 

• Critical failure effects

• Failure modes leading to these effects

• Where additional protection is required

 

We tend to believe that well written and well tested safety critical software would never fail. Experience proves otherwise, with software making headlines when it actually does fail, sometimes critically. Software does not fail the same way hardware does, and the various failure behaviors we are accustomed to from the world of hardware are often not applicable to software. However, software does fail, and when it does, it can be just as catastrophic as hardware failures. The FMEA is not specific for a type of failure behavior or a certain type of failure statistic; it is universal and extremely useful for software as well. When properly done, the FMEA offers an exhaustive and complete review of potential critical failures due to software malfunction.

 

Software, especially in critical systems, tends to fail where least expected. We are usually extremely good at setting up test plans for the main line code of the program, and these sections usually do run flawlessly. Software does not “break” but it must be able to deal with “broken” input and conditions, which are often causes for “software failures”. The task of dealing with abnormal/anomalous conditions and inputs is handled by the exception code dispersed throughout the software program. Setting up a test plan and exhaustive test cases for the exception code is difficult and somewhat subjective by definition. The FMEA removes this difficulty and provides a guide to ensure completeness of the testing and certification process. Anomalous inputs can be due to failed hardware, timing problems, harsh/unexpected environmental conditions and multiple changes in conditions that are beyond the designed hardware capability to deal with. Unexpected user input may also be a source for such exception conditions. Often it is most difficult to predict multiple, coinciding, irregular inputs and conditions.  

 

The FMEA process ensures comprehensive identification of exception condition initiators, and verification that protection against faults in exception handling is in place and effective! Although slightly different from a hardware FMEA, the software FMEA is compatible with hardware FMEAs, if properly executed, and permits a  full system FMEA. Hence it provides the assurance, that other certification processes cannot guarantee , that we have identified all possible failure modes and have included provisions to detect and protect against them.  

 

 

One of the main reasons why the FMEA hasn’t been a consistent part  of critical software certification is the difficulty  in applying it to a large piece of code. ALD has developed a methodology that overcomes this  problem by using the object view of the program. Regardless of the development means such as a UML or MatLab Simulink model, or coded in an object-oriented language such as C++, .Net or Java, we apply our FMEA methodology at the object level. Along with requirements and design documents we are able to construct a software FMEA that is surprisingly similar to a hardware FMEA, as software “objects” are equivalent to hardware “parts”. Moreover, when required, we will develop and  generate a system FMEA which will include hardware, software and any interface failure modes.  

 

Our method overcomes another inherent software FMEA problem that most professionals cannot escape: the subjectivity of the process. Most software safety professionals used to the FMEA at a “functional” level. This methodology is not only problematic since it can leave entire sections of the exception code unevaluated, but it also introduces a subjectivity into the process that allows more failure modes to be ignored. Our object-centered method removes such subjectivity as it uses the classes defined in  the design.  

 

 

ALD's automated FMEA tools allow you to build extensive libraries of failure modes, failure effects, system effects, and detection and mitigation provisions. The libraries enrich the organization knowledge base and directly reduce costs in future efforts both by making early designs safer and by reducing future FMEA efforts. 

 

FMEAs, applied to software or hardware, are time-consuming and labor-intensive tasks. Hardware FMEAs are automated through an exhaustive system breakdown tree, or Bill Of Material. ALD has developed automated tools and methods for generating a complete software FMEA based  on object-oriented software models. Our tools are currently able to automatically generate the FMEA for models developed in UML (Unified Modeling Language) or within the MatLab Simulink environment.

 

Benefits of our automated tools include:

 

• A significant reduction in work load (by  several orders of magnitude)

• Assurance of completeness of the task (no failure modes left behind)

• Libraries for future use that reduce work load even more (software and interface components, failure modes, higher order effects, detection methods,          compensation provisions) 

 

ALD provides both consulting services and tools for the Software FMEA. Our services cover the entire spectrum of your organizational needs:

 

• ALD can perform the entire task of  developing the FMEA for your system and generating the complete set of FMEA reports.  

Or

• ALD can provide consulting to an in-house effort which may include any combination of: training, system set-up, tools and/or continuous program support. 

 

Either way, ALD will walk you through the process so that your organization is able to successfully complete the FMEA and fully trust the results. 

 

• List of critical failure modes and whether they have been accounted for in the design;

• List of provisions (detection methods &  compensation provisions) required to make the current system safe.  

 

At the end of every step or task, the reports and electronic libraries developed in the process will lead to an  easier task in future FMEA efforts. As in the case of hardware, a software FMEA is an incredibly valuable addition to the organizational knowledge base, allowing for safer and less costly programs in the future. 

 

For more information about Software FMEA please contact ALD Support at This email address is being protected from spambots. You need JavaScript enabled to view it.