This Month's Theme is Software FMEA
Next month's theme will be "hazard analysis"

Every month in FMEA Corner, join Carl Carlson, a noted expert in the field of FMEAs and facilitation, as he addresses a different FMEA theme (based on his book Effective FMEAs) and also answers your questions.

Questions and answers are a great way to learn about FMEAs, for both experienced and less experienced FMEA practitioners. Please feel free to ask any question about any aspect of FMEAs. Send your questions to Carl.Carlson@EffectiveFMEAs.com, and your contact information will be kept anonymous. All questions will be answered, even if they are not featured in the FMEA Corner.

 

 
soft·ware [soft-wār, noun]
The Oxford English Dictionary defines "software" as "the programs and other operating information used by a computer."

---

What is Software FMEA?

My software never has bugs. It just develops random features. - Anonymous

Pete Goddard, in his paper "Software FMEA Techniques" (RAMS 2000) wrote, "Software FMEA assesses the ability of the system design, as expressed through its software design, to react in a predictable manner to ensure system safety."

Software FMEA is similar to System or Design FMEA, with the exception that Software FMEA focuses primarily on software functions.

What are objectives for Software FMEA?

Possible objectives for Software FMEA include:

• Identifying missing software requirements
• Analyzing output variables
• Analyzing a system’s behavior as it responds to a request that originates from outside of that system
• Identifying (and mitigating) single point failures that can result in catastrophic failures
• Analyzing interfaces in addition to functions
• Identifying software response to hardware anomalies

When should Software FMEA be used?

Many mechanical and electrical systems include software integration. The FMEA methodology applies very well to software as well as hardware. It is possible to include software functionality in the System FMEA as part of the functional descriptions. However, especially for complex software functionality such as embedded control systems, it may be useful to perform a separate software FMEA.

What standard is used?

There is no universally agreed-upon standard for performing software FMEAs, although it is the subject of various standards committees. Practitioners who will be performing software FMEA projects are encouraged to read the software standards and articles that apply to their projects. In addition, it is essential for any software FMEA team to include a subject matter expert in the specific software systems that are being analyzed.

Does the Effective FMEAs book include information on Software FMEAs?

Effective FMEAs has a section on Software FMEAs in chapter 15. It includes a general description of Software FMEA, the different types of Software FMEAs, the relationship between Software FMEA and Software Hazard Analysis, the general procedure for Software FMEAs, examples of Software FMEAs and references.

What precedence guidelines can be used to address software problems?

FMEA recommended actions can use the following order of precedence to help ensure software is fail-safe and accomplishes its functions, with heightened focus on potential hazardous outcomes. Special attention should be paid to identify any need for new or modified software requirements.

1. Design out the failure mode
2. Use redundancy to achieve fault tolerance
3. Go into fail-safe mode (for example, the ability to "limp home")
4. Implement early prognostic warning
5. Implement training to reduce risk for human error

What is "fail safe" and how is it used in software?

The software should always go to the desired state no matter what causes the software to malfunction. If a desired state is not identified in the specification, the software should always go into fail-safe state. A fail-safe state is one that, in the event of failure, responds in a way that will cause minimal harm to other devices or danger to personnel.

Software programmers should consider fail-safe strategies to help ensure systems are safe and robust.

How early in the design process should Software FMEAs be done?

Similar to System FMEAs, software FMEAs at the system level should be performed early in the design process, as soon as the software design team has determined initial software architecture and transferred the functional requirements to the software design. Software FMEAs at the detail level are typically done later in the software design process, when detailed design description and preliminary code exists.

Software FMEA references and standards

In addition to the material covering Software FMEA in Effective FMEAs, the following are some references and standards for Software FMEA:

• IEC 61508, Functional safety of electrical/electronic/programmable electronic safety-related systems, 2005.
• NIST (National Institute of Standards and Technology), Planning Report 02-3, The Economic Impact of Inadequate Infrastructure for Software Testing, May 2003.
• SAE JA 1002, Software Reliability Program Standard, January 2004.
• Raheja, Dev, Assurance Technologies: Principles and Practices, McGraw-Hill, 1991.
• Raheja, Dev, SAE 2005-01-0817: "Software FMEA: A Missing Link in Design for Robustness," copyright 2005 SAE International.
• Goddard, P.L., Software FMEA Techniques, Proceedings of the Annual Reliability and Maintainability Symposium, January 2000.
• Herbert Hecht, Xuegao An, Myron Hecht, Computer Aided Software FMEA for Unified Modeling Language Based Software, Proceedings of the Annual Reliability and Maintainability Symposium, January 2004.
• Ozarin, Nathaniel, Developing Rules for Failure Modes and Effects Analysis of Computer Software, SAE Congress Paper 2003-01-2987.
• John B. Bowles, Chi Wan, Software Failure Modes and Effects Analysis for a Small Embedded Control System, Proceedings of the Annual Reliability and Maintainability Symposium, January 2001.
• NIST (National Institute of Standards and Technology), Planning Report 02-3, The Economic Impact of Inadequate Infrastructure for Software Testing, May 2003.

How can Xfmea support Software FMEA?

Xfmea can support a wide variety of FMEA standards and worksheet profiles. The following is an incomplete Software FMEA example provided by Dev Raheja, using Xfmea. In this example, the AIAG standard is used. Practitioners can easily modify the standard to fit any worksheet profile and add it to their Xfmea library.

---

FMEA Tip of the Month

When a system configuration includes either embedded software or other software functionality, the FMEA team needs to decide how to include software within the scope of the FMEAs being performed. There are two primary approaches the team can consider. One approach is to include software functionality in the System FMEA, as part of the functional descriptions. Another approach, especially for complex software functionality such as embedded control systems, is to perform a separate software FMEA.

Something I’ve always wanted to know about FMEAs
The important thing is not to stop questioning. - Albert Einstein

A reader submitted the following question to Carl Carlson. To submit your own question about any aspect of FMEA theory or application, e-mail Carl at Carl.Carlson@EffectiveFMEAs.com. (All questions and responses will be kept anonymous).

I wanted to first tell you that your article about the P-Diagram is very informative.

I have a couple questions I would like to ask you to point me in the right direction.

1. Should I use the P-Diagram to analyze every single function? In other words I am not sure if placing each individual function in the system block is the proper way to use the P-Diagram.

2. While I understand how the Noise, Errors, Controls, etc. are related to FMEA, would I use the system block as a function in the FMEA document?

Carl: To answer your first question, I'll quote from my book.

P-Diagram is at the Item level, not at the Function level. In other words, there is one P-Diagram for a given system or subsystem, not for each function in the system or subsystem. The information in the Ideal Response block of the P-Diagram becomes input to the Function descriptions in the corresponding FMEA.

In answer to your second question, the System block represents the entire system. As covered above, the information in the Ideal Response block of the P-Diagram becomes input to the Function descriptions in the corresponding FMEA.

---

Carl S. Carlson is a consultant and instructor in the areas of FMEA, reliability program planning and other reliability engineering disciplines. He has 35 years of experience in reliability testing, engineering and management positions, and is currently supporting clients from a wide variety of industries, including clients of HBM Prenscia. Previously, he worked at General Motors, most recently senior manager for the Advanced Reliability Group. His responsibilities included FMEAs for North American operations, developing and implementing advanced reliability methods and managing teams of reliability engineers. Previous to General Motors, he worked as a Research and Development Engineer for Litton Systems, Inertial Navigation Division. Mr. Carlson co-chaired the cross-industry team that developed the commercial FMEA standard (SAE J1739, 2002 version), participated in the development of SAE JA 1000/1 Reliability Program Standard Implementation Guide, served for five years as Vice Chair for the SAE's G-11 Reliability Division and was a four-year member of the Reliability and Maintainability Symposium (RAMS) Advisory Board. He holds a B.S. in Mechanical Engineering from the University of Michigan and completed the 2-course Reliability Engineering sequence from the University of Maryland's Masters in Reliability Engineering program. He is a Senior Member of ASQ and a Certified Reliability Engineer.

Selected material for FMEA Corner articles is excerpted from the book Effective FMEAs, published by John Wiley & Sons, ©2012. Information about the book Effective FMEAs, along with useful FMEA aids, links and checklists can be found on www.effectivefmeas.com. Carl Carlson can be reached at carl.carlson@effectivefmeas.com.

Copyright ©  HBM Prenscia Inc., ALL RIGHTS RESERVED.