Automated FMEA

Architectural rendering and analysis of the system Software architecture refers to a structured conceptual representation of a software system. Software architectural rendering of a system serves as a framework from which more detailed design activities can be developed. Software architecture first defines top hierarchical or modular components of the system that are sufficient to represent the system. The details of each modular component could then be addressed in further design. Failure analysis could start at the top. After analysis at the first level, modifications are suggested and implemented. After this level, work is complete, and then one can proceed to the next level down in this way the entire system can be analyzed. With this, discussions on FMEA for E/E/PE is concluded to explore the possibility of automating FMEA. 

Some efforts have been made to compare the two kinds of FMEA manual and automated. Since in automated FMEA there are several methods, many of the comparison points mentioned in Table IV/2.6.1-1 may differ and there could be a few more additional points too. 

Why Automated FMEA Further to what was discussed earlier, the traditional approach has a few other serious drawbacks, for example, it is not suitable for reuse and information retrieval is extremely difficult for reuse especially when traditional FMEA grows. Also it is difficult for traditional FMEA to meet the demands of frequent changes in design. At the same time, FMEA is not much use when it is conducted at an early stage and information availability is scant. So, traditional FMEA created after engineering is done may be of no value if it does not cater for the requirements of changes in design as stated earlier. Therefore traditional FMEA may be a nonvalue-added activity created just to satisfy the contractual requirements of customers ... 

Therefore the requirements of automated FMEA are now being appreciated and work toward this approach is increasing. Major work in this area has been found in... 

Table rV/2.6.1-1 Comparison of Manuid and Automated FMEA (Qeneric) ... 

To get a feel of the fuzzy definition set, detection likelihood, as shown in Fig. lV/2.2.3-1, has been transformed into a fuzzy definition. A typical fuzzy membership is shown in Fig. lV/2.6.4-2. Actual fuzzy values are derived based on the fuzzy rule set. Fuzzy inputs are evaluated using a rule-based set, so that criticality and RPN calculations can be made. In the fuzzification process, with help of crisp ranking, set S O D is converted into fuzzy representation so that these can be matched with the rule base. Here, the if then rule has two parts an antecedent (which is compared to input) and consequence (which is the result). On the other hand, in the defuzzification process, the reverse takes place. It is possible to automate FMEA using fuzzy logic and rule-based systems. The rule allows quantitative data such as occurrence to be easily combined with judgmental and quantitative data (such as severity and detectability) very easily and uniformly. The rule based on the linguistic variables is more expressive and useful (for further reading see Ref. [11]). 

Automated FMEA and Little JIL Process Definition Language... 

In this method, automated FMEA is done with the help of process modeling in sufficient detail using Little-JIL process definition language (see Appendix IV). Little-JIL process definition is a hierarchy of steps, representing a single unit of work. Every step specifies all artifacts and resources it uses in its interface. A step without any substeps is called a leaf step. Each nonleaf step has a sequencing badge that indicates the execution order of its substeps. Artifacts are objects passed between different steps via four parameter types, IN, OUT, IN/OUT, and Locals parameter. In Little-JIL, resources are special kinds of artifacts for which there is contention for access [11]. 

In this automated FMEA three basic steps are applied ... 

B. Jenkins, Automating FMEA Next Generation Failure Analysis from NANEVA, Ora Research LLC (2013). 

For this, each type discussed in the preceding needs to be addressed, maybe separately, by Little JIL. Therefore Little JIL language can be applied in automating FMEA/FTA for finding failure modes in large and complex systems. 

For example, the characteristic dimension A on the cover support leg was critical to the success of the automated assembly process, the potential failure mode being a major disruption to the production line. An FMEA Severity Rating (S) = 8 is allocated. See a Process FMEA Severity Ratings table as provided in Chrysler Corporation et al. (1995) for guidance on process orientated failures. The component cost, Pc = 5.93 and the number planned to be produced per annum, N = 50000. 

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... 

In reliability analyses we could refine the automation system performance by a decomposition of software fault to separate basic events according to their different CCF potential. A Failure Mode and Affect Analysis /FMEA/ of software could serve as an information basis for such a task. The level of decomposition could be from a basic, like... 

Now, efforts have been made to develop suitable software for various methods of plant (process) hazard analysis (PHA). There are a number of papers available where through suitable software it is possible not only to automate one PHA method but to integrate several automated PHA methods such as event tree/fault tree (Chapter V) with HAZOP or HAZOP with FMEA, which will be discussed in the next clause in this chapter. 

N. Huges, E. Chou, C. Price, M. Lee, Automating Mechanical FMEA Using Functional Models, University of Wales, UK American Association for Artificial Intelligence, 1998. 

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

For automation of hazard analyses such as FMEA/FTA, use of architecture analysis design language (AADL) is quite common. Modeling language AADL is standardized by SAE (2008 version). Major uses of AADL includes, but not limited to, the... 

In this paper, we propose an approach for characterizing failure effects on AADL models by automatically detecting effect relations over the state space underlying the AADL model. This is of particular value to the automated generation of precise FMEA tables, although not being limited to this application. Our approach is also not limited to AADL models, but is of a more general nature. An effect matrix can be computed for any model equipped with a formal semantics that describes its behavior by means of a labeled transition system. Furthermore,... 

Price C.J., Pugh D.R., Wilson M.S. and Snooke N., (1995) The Flame System Automating Electrical Failure Mode Effects Analysis (FMEA) , Proceedings Annual Reliability and Maintainability Symposium, pp. 90-95. 

---