“My software never has bugs. It just develops random features.” Anonymous
More and more 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, for complex software functionality such as embedded control systems, it may be useful to perform a separate software FMEA.
What is a Software FMEA?
Software FMEA is a type of Design FMEA that analyzes the software elements, focusing on potential software-related deficiencies, with emphasis on improving the software design and ensuring product operation is safe and reliable during useful life.
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?
Objectives for software FMEA include:
• Identifying missing software requirements
• 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
• Identifying features that need fault-handling strategies
• Identifying software response to hardware anomalies
What is the difference between Software FMEA and hardware or electrical FMEAs?
All types of FMEAs are grounded in similar principles and fundamentals. The primary difference with software FMEA is the focus of the analysis.
For example, in the case of a software module that provides a warning for low-level of windshield washer fluid, the Item in the Software FMEA can be “Low washer fluid level warning software” and the Function might be “Communicate low fluid level to instrument panel.” A single-line excerpt from this software FMEA example is in the updated SAE J1739 FMEA Standard, due to be published in January 2021.
Other differences between Hardware and Software FMEAs include:
1. Software failure modes are analyzed from unique modes of operation, compared to hardware
2. Software has unique set of failure mode and cause categories
3. Software FMEA analyzes how software reacts to hardware failures
4. Can be minor difference between Design FMEA and Software FMEA template
Software Modes of Operation
Understanding the unique modes of operation for software helps ensure nothing important is messed. 
1. Functional (new requirements or significant revision)
2. Interface (complex hardware or software interfaces)
3. Detailed (high-risk items)
4. Maintenance (older legacy system prone to errors)
5. Usability (when user misuse can impact system reliability)
6. Serviceability (mass distribution or difficult installation location)
7. Vulnerability (risk from hacking or abuse)
8. Production (system schedule is disrupted by software production process)
 Recognition is due to Ann Marie Neufelder, whose book “Effective Application of Software Failure Modes Effects Analysis – 2nd Edition” is an excellent resource for anyone performing Software FMEAs. (Copyright © 2017 by Softrel, LLC., published by Quanterion Solutions, Inc., Utica, New York)
Software Common Cause Categories
What are some of the unique software cause categories? 
1. Missing error detection (missing in specifications, design and code)
2. Specifications missing important details (review process can miss what is NOT in code, design or requirements)
3. Faulty state transitions (leads to dead states, inadvertent / prohibited state transitions, etc.
4. Faulty logic (when software fails to consider all possibilities from logic perspective)
5. One size fits all error recovery (detecting and recovering from errors should be specific to circumstances)
Level of detail
Software FMEA can be applied at the system functional level, the detailed design (logic level) or at the code level.
Similar to System FMEAs, software system FMEAs 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.
What precedence-guidelines can be used to address software problems?
When identifying Recommended Actions, Software FMEA teams can use the following precedence suggestions in order to ensure the 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. 
a. Design out the failure mode
b. Use redundancy to achieve fault tolerance
c. Go into fail-safe mode (for example, the ability to “limp home”)
d. Implement early prognostic warning
e. Implement training to reduce risk for human error
 Reference article titled “Software FMEA: A Missing Link in Design for Robustness,” by Dev Raheja, copyright 2003 by SAE International
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.
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.
As mentioned above, Ann Marie Neufelder’s book “Effective Application of Software Failure Modes Effects Analysis” is an excellent resource for anyone performing Software FMEAs.
Understanding software potential trigger events can improve the effectiveness of Software FMEA and ensure important issues are addressed.
1. Consider potentially critical hardware failures or user misuse when performing Software FMEA. Software must be robust to potential hardware failures or user misuse, and must default to safe condition.
2. Potentially critical hardware failures or user misuse can be derived from System FMEA, lower-level FMEAs, Hazard Analysis or Fault Tree Analysis.
3. Lack of robustness or lack of default to safety condition can be input to software FMEA cause descriptions. Note, Software FMEA causes should be expressed as a potential software deficiency.
Hazard analysis is the process of examining a system throughout its life cycle to identify inherent safety related risks. The next article in the Inside FMEA series discusses the application of Hazard Analysis.