Software FMEA

Application to the Tihangel software FMEA SPINUNE3 software components relevant for FMEA... 

The Bl is the basic component used for the software FMEA The correct behavior of a Bl is characterized by the following ... 

Lessons learned from the SPINLINE3 OSS software FMEA... 

In this paper, we have presented this software FMEA experienee including adaptation of the principles of FMEA to analyze a software program choice of a block of instmction (BI) approach to identify the components to analyze definition of the software failure modes associated with the Bis examples of the analyses performed on the SPINLINE3 Operational System Software feedback of experience... 

As discussed earlier there are some differences between hardware and software FMEA. 

Drawn inspired by document referenced O. Mackel, Software FMEA—Opportunities and Benefits of FMEA in Development Process of Software—Intensive Technical Systems, Siemens, AG. 

Software often has very nonuniform qualities in terms of the effects of potential failures. Efforts have been made to develop an automatic model for software FMEA. The major steps involved are ... 

C. Price, N. Snooke, An automated software FMEA, in International System Safety Regional Conference, Aberystwyth University, Singapore, April 2008. 

Architectural design analysis Once the requirements phase has been completed, the software team passes on to the top-level systems design. As the design is laid out, the criticality analysis tracking system is updated with the new, more detailed information. This is performed primarily through software hazard analysis. Another tool is software FMEA. 

The failure modes and probabilities for hardware components are normally well known. Although failure modes of software are more complex and coupled with a certain degree of uncertainty, Reifer and others [5], [6] showed the benefits of performing a Software-FMEA (SFMEA). As explained in [7] when an SFMEA is performed early in the design phase of software, activities for verification and validation of software are easier to execute and a more focused use of development effort is possible. 

This paper describes an approach for the combined analysis of safety and security. The basic FMEA concept is extended to include vulnerabilities and attacks concerning the security of a system. A unified cause and effect model allows examining the combined risks for a system. The following method for a Failure Mode, Vulnerabilities and Effects Analysis (FMVEA) enables the analysis of complex mission critical systems. Similar to a Software-FMEA the benefits are the easier verification and validation and the ability to focus the development effort on critical areas. 

Keywords System Safety Complexity Safety Analysis Software Engineering Formal Methods OF-FMEA Safety Claim Structure Safety Case Safety Assessment... 

Failure Modes and Effects Analysis (FMEA) and its variants have been widely used in safety analyses for more than thirty years. With the increase of application domain of software intensive systems there was a natural tendency to extend the use of (originally developed for hardware systems) safety analysis methods to software based systems. 

Cichocki, T. and J. Gorski, OF-FMEA—an approach to safety analysis of object oriented software intensive system, The International Conference on Advanced Computer Systems (ACS 2002), Miedzyzdroje (Poland), October 23-25, 2002 (published in The Kuwer International Series in Engineering and Computer Science - 752, ISBN 1-4020-7396-8, September 2003, p. 271-280). 

FMEA is best applied by a multidisciphnary team reviewing the design of a computer system. As with CHAZOPs, team members are selected for their particular knowledge of the production process, the computer system, and the software. The team steps through various computer system failures, considering their effect, risk, and how they might be controlled. The outcome of a FMEA is then documented in a template such as the example given in Table 8.3. 

More sophisticated FMEAs examine the level of concern over various hazards in terms of GxP criticality. Figure 8.9 describes how to determine three levels of concern low, medium, and high. The decision tree presented considers only the impact on drug product quality. Some pharmaceutical and healthcare companies may want to include operator safety, business impact, and even the GAMP categories of software affected in their determination of these levels of concern. ... 

Conlignrable and cnstomized COTS software and bespoke (cnstom) hardware shonld be snbject to an HACCP, CHAZOP, or FMEA as appropriate. It is vital that GxP processes are not compromised. The following qnestions should be rhetorically posed ... 

Nonconfigurable COTS software and standard hardware do not require an HACCP, CHAZOP or FMEA if operational experience exists to support the view that the COTS products are stable and robust. Operating experience should be considered suitable when the following criteria are met ... 

Results of clinical trials Threats and Controls FMEA, Software Structure Analysis IQ, OQ, and PQ tests and Fundamental Science Document Relevant to medical device as a whole not directly applicable to its automation... 

FMEA Performed on the SPINLINE3 Operational System Software as part of the TIHANGE 1 NIS Refurbishment Safety Case... 

It then focuses on the specificity of FMEA performed on software. It points out the benefits of this analysis and also some of the limitations and possible developments. It also gives characteristics that, if present in the sojtware, help the analysis and the defenses. 

Performing a FMEA on the software is a mean to narrow the scope of the demonstration by finding out the software components that may, if faulty, lead to a CCF. It is then easier to show, either that those software components are error free or that the postulated component failure modes will be detected and will lead to a safe position. This analysis has been performed on the Operational System Software and on the Application Software for the new TIHANGE 1 Nuclear Instrumentation System (NIS). 

It has been recognized that the methods and tools used for the software development and V V, the respect of the requirements of lEC 60880, the experience of the software teams were suitable to produce software as error free as possible . This has been proven by the feedback of experience gained on similar projects that we have developed during the last 20 years. We have nevertheless been required to perform an additional analysis on the IE software, using an FMEA technique, in order to identify those parts of the... 

In the next section of this paper, we introduce the principle of the FMEA performed on the Tihangel software and discuss some of the results found, using this technique. 

The Failure Mode and Effects Analysis (FMEA) is a systematic, bottom-up method of identifying the failure modes of a system, item, function and determining the effects on the higher level. It may be performed at any level within the system (e.g., piece-part, function, blackbox, etc,). Software can also be analyzed qualitatively using a functional FMEA approach. Typically, a FMEA is used to address failure effects resulting from single failures [1]... 

When performing an FMEA on software, very few information or support is available. The safety engineer has to apply his own knowledge of software to set up an FMEA approach, i.e. ... 

The tests provided by the FMEA are not intended to be a proof that the software is free of SCCFs. They are not sufficient when testing is not exhaustive, which is the most frequent situation. They can only be used as a demonstration added to the technical and quality dispositions taken for the development and the V V of the software. 

The FMEA has not caused significant changes in the development process and technical rules used to produce IE software in our department. Rules for software fault prevention and mitigation were already defined in our methodology and have provided acceptable prevention for SCCF situations identified by the FMEA. 

Performing the FMEA for the Tihange 1 project has proved to be a good way to discuss in depth safety aspects of software-based systems with our customer and with the licensing authority. 

The safety characteristics of the SP1NL1NE3 solution and the stringent and proven safety software development process applied by the Nuclear department of the Schneider Electric company have made acceptable the principle of a design based on redundant identical processing units for this project. In addition, because of the possible consequences in case of the NIS not performing its protection fonction on demand, the licensing authority has required an FMEA oriented toward the SCCF risk as part of the safety case. 

The FMEA methodology is now extensively used in a variety of industries including semiconductor processing, food service, plastics, software and health care, where it is sometimes integrated into Advanced Product Quality Planning (APQP) to provide a primary design and process risk mitigation tool. 

---