RISK CHARTS FOR FAILURE MODE AND EFFECT ANALYSIS

Abstract

A method to facilitate a failure modes and effects analysis (FMEA) project associated with one or more components or process during a product development cycle is provided. The method includes displaying on the user interface one or more information pages associated with sequential order of elements to be completed by one or more FMEA analysts. The method further involves receiving with an aid of the user interface textual inputs from the one or more FMEA analysts for the one or more information pages associated with the sequential orders of elements. The method further includes developing a risk chart for tracking a risk mitigation progress for the FMEA project associated with the one or more components or process during the product development cycle. The risk charts include a Criticality Matrix Risk Chart (CMRC) and a Pro-active Reliability Risk Chart (PRRC).

Description

RELATED APPLICATIONS

This application is based upon and claims the benefit of priority from U.S. Provisional Applications No. 61/470,744 by Jason Wayne Flanagan et al., filed Apr. 1, 2011, and U.S. Provisional Application No. 61/470,715 by Jasmeen K. Harsh et al., filed Apr. 1, 2011, the contents of which are expressly incorporated herein by reference.

TECHNICAL FIELD

The present disclosure generally relates to Failure Mode and Effects Analysis (FMEA) and more particularly to develop risk charts in FMEA.

BACKGROUND

Every product or process is subject to different types or modes of failure. Potential failures may have costly consequences or effects. Hence, it is essential to effectively and efficiently monitor the entire production cycle of the product and its manufacturing process in order to identify the potential failures and the associated relative risks at an early stage and achieve a better quality product.

Generally, Failure Mode and Effect Analysis (FMEA) is conducted in order to identify causes and effects of the potential failure in the manufacturing process and/or the design of the product, prioritize action plans to reduce the potential failures, track and evaluate results of the action plans and eventually minimize or eliminate the potential failure and the associated risk. The FMEA may be conducted for a design of the product or for a process of manufacturing the product.

Typically, FMEAs are conducted manually, involving the use of excel spread sheets. This known technique proves to be time consuming and cumbersome in situations where the FMEA is being conducted for a product having a relatively large number of parts or numerous process steps. Additionally, the technique is prone to human errors. Moreover, in some instances, manually monitoring the progress of the FMEA, tracking the progress of the action plans or evaluating the success of risk mitigation may be difficult and challenging.

Therefore, there is a need for an automated system and method for performing the FMEA process and enabling an analyst to monitor and track the progress of risk mitigation.

SUMMARY OF THE DISCLOSURE

In an aspect of the present disclosure, a computer-implemented method is provided to facilitate a failure modes and effects analysis (FMEA) project associated with one or more components or process during a product development cycle. A real time FMEA status is viewable through a user interface which indicates the progress of the FMEA project. The method includes displaying on the user interface one or more information pages associated with sequential order of elements to be completed by one or more FMEA analysts. The method further involves receiving with an aid of the user interface textual inputs from the one or more FMEA analysts for the one or more information pages associated with the sequential orders of elements. Further, the method includes developing a risk chart for tracking a risk mitigation progress for the FMEA project associated with the one or more components or process during the product development cycle. The risk charts include a Criticality Matrix Risk Chart (CMRC) and a Pro-active Reliability Risk Chart (PRRC).

In another aspect of the present disclosure, a system is provided that includes a processor for facilitating a failure modes and effects analysis (FMEA) project associated with one or more components or process during a product development cycle. The system also includes a tangible, non-transitory memory configured to communicate with the processor, the tangible, non-transitory memory having instructions stored thereon that, in response to execution by the processor. The processor performs the operation of displaying a real time FMEA status is viewable through a user interface which indicates the progress of the FMEA project. The processor further performs the operation of displaying on the user interface one or more information pages associated with sequential order of elements to be completed by one or more FMEA analysts. The processor further performs the operation of receiving with an aid of the user interface textual inputs from the one or more FMEA analysts for the one or more information pages associated with the sequential orders of elements. Further, the processor performs the operation of developing a risk chart for tracking a risk mitigation progress for the FMEA project associated with the one or more components or process during the product development cycle. The risk charts include a Criticality Matrix Risk Chart (CMRC) and a Pro-active Reliability Risk Chart (PRRC).

In yet another aspect of the present disclosure, an article of manufacture is provided that include a non-transitory, tangible computer readable medium having instructions stored thereon that, in response to execution by a computer-based system for facilitating a failure modes and effects analysis (FMEA) project associated with one or more components or process during a product development cycle. The computer-based system is configured to perform operation of displaying a real time FMEA status is viewable through a user interface which indicates the progress of the FMEA project. The computer-based system is further configured to perform operation of displaying on the user interface one or more information pages associated with sequential order of elements to be completed by one or more FMEA analysts. The computer-based system is further configured to perform operation of receiving with an aid of the user interface textual inputs from the one or more FMEA analysts for the one or more information pages associated with the sequential orders of elements. Further, the computer-based system is configured to perform operation of developing a risk chart for tracking a risk mitigation progress for the FMEA project associated with the one or more components or process during the product development cycle. The risk charts include a Criticality Matrix Risk Chart (CMRC) and a Pro-active Reliability Risk Chart (PRRC).

Other features and aspects of this disclosure will be apparent from the following description and the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an overview of an exemplary environment in which an Graphical User Interface (GUI) module to facilitate a failure modes and effects analysis (FMEA) project may be deployed, in accordance with various embodiments of the present disclosure;

FIG. 2 is an exemplary implementation of the GUI module for facilitating the FMEA project, according to an embodiment of the present disclosure;

FIG. 3 is an exemplary user interface window for selecting a type of the FMEA project, according to an example embodiment of the present disclosure;

FIG. 4 is an exemplary user interface window for creating a selected type of FMEA project, according to an example embodiment of the present disclosure;

FIG. 5 is an exemplary user interface window for receiving information associated with the FMEA project, according to an example embodiment of the present disclosure;

FIG. 6 is an exemplary user interface window for linking one or more projects with the FMEA project, according to an example embodiment of the present disclosure;

FIG. 7 is an exemplary user interface window for displaying a FMEA navigator under the FMEA project, according to an example embodiment of the present disclosure;

FIG. 8 is an exemplary user interface window to add one or more team members associated with the FMEA project, according to an example embodiment of the present disclosure;

FIG. 9 is an exemplary user interface window for creating a session associated with the FMEA project, according to an example embodiment of the present disclosure;

FIG. 10 is an exemplary user interface window for creating an item under the FMEA project, according to an example embodiment of the present disclosure;

FIG. 11 is an exemplary user interface window for receiving additional information associated with the item in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 12 is an exemplary user interface window for editing information associated with the item in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 13 is an exemplary user interface window for providing one or more requirements associated with the item in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 14 is an exemplary user interface window for adding one or more failure modes associated with the requirements in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 15 is an exemplary user interface window for providing additional information associated with the failure modes in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 16 is an exemplary user interface window for editing the information associated with the failure modes in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 17 is an exemplary user interface window for adding one or more potential effects of failure associated with the failure modes in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 18 is an exemplary user interface window for adding one or more potential causes of failure associated with the failure modes in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 19 is an exemplary user interface window for providing additional information associated with the potential causes of failure in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 20 is an exemplary user interface window for selecting one or more controls for the FMEA project, according to an example embodiment of the present disclosure;

FIG. 21 is an exemplary user interface window for adding detection controls for the potential cause of failure in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 22 is an exemplary user interface window for providing information associated with the detection control in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 23 is an exemplary user interface window for displaying the detection control in a tree structure format in the FMEA navigator, according to an example embodiment of the present disclosure;

FIG. 24 is an exemplary user interface window for adding one or more prevention controls in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 25 is an exemplary user interface window for displaying the prevention control in a tree structure format in the FMEA navigator, according to an example embodiment of the present disclosure;

FIG. 26 is an exemplary user interface window for adding one or more recommended actions in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 27 is an exemplary user interface window for selecting a type of recommended action in the FMEA project, according to an example embodiment of the present disclosure;

FIGS. 28-31 are exemplary user interface windows for providing information associated with the recommended actions in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 32 is an exemplary user interface window for displaying the recommended action in a tree structure format in the FMEA navigator, according to an example embodiment of the present disclosure;

FIG. 33 is an exemplary user interface window for editing the information associated with the recommended action in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 34 is an exemplary user interface window for adding product information in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 35 is an exemplary user interface window for displaying a real time FMEA status as a Summary in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 36 is an exemplary user interface window for presenting a status report run from Summary in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 37 is an exemplary user interface window for viewing projects associated with a FMEA analyst, according to an example embodiment of the present disclosure;

FIG. 38 is an exemplary user interface window for viewing information under Design Verification Plan and Report (DVP&R) in the FMEA project, according to an example embodiment of the present disclosure;

FIGS. 39-41 is an exemplary user interface window for syncing and replacing a plurality of FMEA projects in a validation project, according to an example embodiment of the present disclosure;

FIG. 42 is an exemplary user interface window for presenting a Criticality Matric Risk Chart (CMRC) in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 43 is an exemplary user interface window for comparing an initial CMRC with a current CMRC in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 44 is an exemplary user interface window to view a report from the CMRC in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 45 is an exemplary user interface window for presenting a Pro-active Reliability Risk Chart (PRRC) in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 46 is an exemplary user interface window for providing information in a coverage table in the FMEA project, according to an example embodiment of the present disclosure;

FIG. 47 is an exemplary user interface window for providing information in a coverage table in the validation project, according to an example embodiment of the present disclosure;

FIG. 48 is a block diagram of an exemplary computer-based system, according to an example embodiment of the present disclosure; and

FIG. 49 is an exemplary process flow for facilitating the FMEA project, according to an example embodiment of the present disclosure.

DETAILED DESCRIPTION

The detailed description of exemplary embodiments in the disclosure herein makes reference to the accompanying drawings and figures, which show the exemplary embodiments by way of illustration only. While these exemplary embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure, it should be understood that other embodiments may be realized and that logical and mechanical changes may be made without departing from the spirit and scope of the disclosure. It will be apparent to a person skilled in the pertinent art that this system can also be employed in a variety of other applications. Thus, the detailed description herein is presented for purposes of illustration only and not of limitation. For example, the steps recited in any of the method or process descriptions may be executed in any order and are not limited to the order presented.

The present disclosure is described herein with reference to block diagrams and flowchart illustrations of methods, and computer program products according to various aspects of the disclosure. It will be understood that each functional block of the block diagrams and the flowchart illustrations, and combinations of functional blocks in the block diagrams and flowchart illustrations, respectively, can be implemented by computer program instructions.

These computer program instructions may be loaded onto a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions that execute on the computer or other programmable data processing apparatus create means for implementing the functions specified in the flowchart block or blocks. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

Accordingly, functional blocks of the block diagrams and flow diagram illustrations support combinations of means for performing the specified functions, combinations of steps for performing the specified functions, and program instruction means for performing the specified functions. It will also be understood that each functional block of the block diagrams and flowchart illustrations, and combinations of functional blocks in the block diagrams and flowchart illustrations, can be implemented by either special purpose hardware-based computer systems which perform the specified functions or steps, or suitable combinations of special purpose hardware and computer instructions. Further, illustrations of the process flows and the descriptions thereof may make reference to user windows, prompts, etc. Practitioners will appreciate that the illustrated steps described herein may comprise in any number of configurations including the use of windows, hypertexts, hyperlinks, popup windows, prompts and the like. It should be further appreciated that the multiple steps as illustrated and described may be combined into single windows but have been expanded for the sake of simplicity. In other cases, steps illustrated and described as single process steps may be separated into multiple windows but have been combined for simplicity.

It is further noted that a “user device” may include, for example, any of computer, laptop, mobile phone, cellular telephones, beepers, pagers, iPods®, personal digital assistants (PDAs), Blackberry® type devices and/or any device capable of receiving and presenting emails.

The systems, methods and computer program products disclosed in conjunction with various embodiments of the present disclosure are embodied in systems and methods for facilitating Failure Mode and Effect Analysis (FMEA) during a product development cycle.

The present disclosure is described in more detail herein in terms of the above disclosed exemplary embodiments of system, processes and computer program products. This is for convenience only and is not intended to limit the application of the disclosure. In fact, after reading the following description, it will be apparent to one skilled in the relevant art(s) how to implement the following system in alternative embodiments.

FIG. 1 is an overview of an exemplary environment 100 for facilitating FMEA, in accordance with various embodiments of the present disclosure. The environment 100 includes a server 102, a repository 104, a user device 106, a communication network 108 and a Graphical User Interface (GUI) module 110. The server 102, the repository 104, the user device 106 and the GUI module 110 may communicate with each other over the communication network 108. Examples of the communication network 108 may include a wide area network (WAN), a local area network (LAN), an Ethernet, Internet, an Intranet, a cellular network, a satellite network, or any other suitable network for transmitting data. The communication network 108 may be implemented as a wired network, a wireless network or a combination thereof. In an embodiment, the GUI module 110 may be accessed through the server 102, by the user device 106 for facilitating the FMEA associated with one or more components or process during the product development cycle.

User device 106 may be any device capable of communicating with the server 102. In one embodiment, a user (herein after referred to as FMEA analyst) may have the user device 106 to communicate with the server 102 on which the graphical user interface module 110 may be deployed. In one example, the user device 106 may be a data processing system such as, for example, a mobile device, any suitable personal computer, a laptop, minicomputer, Personal Digital Assistant (PDA), or the like. Those skilled in art can appreciate that user device 106 includes an operating system (e.g., Windows NT, 95/98/2000, OS2, UNIX, Linux, Solaris, MacOS, etc.) as well as various conventional support software and drivers typically associated with computer. The user device 106 may also include an internal memory, an external memory and a cache. The user device 106 may also include one or more browsers (e.g., Microsoft® Internet explorer, Mozilla® Firefox, etc.) through which an email server may be accessed. Alternatively, user device 106 may include a user email program such as a Microsoft® Outlook, Mozilla® Thunderbird, Pegasus® Mail, and the like, for downloading, reading, replying and/or forwarding the email. Although, a single user device is illustrated herein for exemplary purposes, one skilled in art can appreciate that there can be more than one user device.

The repository 104 and/or one or more databases associated with the GUI module 110 may employ any type of database, such as relational, hierarchical, graphical, object-oriented, and/or other database configurations. Common database products that may be used to implement the databases include DB2 by IBM (White Plains, N.Y.), various database products available from Oracle Corporation (Redwood Shores, Calif.), Microsoft Access or Microsoft SQL Server by Microsoft Corporation (Redmond, Wash.), or any other suitable database product. Moreover, the databases may be organized in any suitable manner, for example, as data tables or lookup tables. Each record may be a single file, a series of files, a linked series of data fields or any other data structure. Association of certain data may be accomplished through any desired data association technique such as those known or practiced in the art. For example, the association may be accomplished either manually or automatically. Automatic association techniques may include, for example, a database search, a database merge, GREP, AGREP, SQL, using a key field in the tables to speed searches, sequential searches through all the tables and files, sorting records in the file according to a known order to simplify lookup, and/or the like. The association step may be accomplished by a database merge function, for example, using a “key field” in pre-selected databases or data sectors.

More particularly, a “key field” partitions the database according to the high-level class of objects defined by the key field. For example, certain types of data may be designated as a key field in a plurality of related data tables and the data tables may then be linked on the basis of the type of data in the key field. The data corresponding to the key field in each of the linked data tables is preferably the same or of the same type. However, data tables having similar, though not identical, data in the key fields may also be linked by using AGREP, for example. In accordance with one aspect of the system, any suitable data storage technique may be utilized to store data without a standard format. Data sets may be stored using any suitable technique, including, for example, storing individual files using an ISO/DEC 7816-4 file structure; implementing a domain whereby a dedicated file is selected that exposes one or more elementary files containing one or more data sets; using data sets stored in individual files using a hierarchical filing system; data sets stored as records in a single file (including compression, SQL accessible, hashed via one or more keys, numeric, alphabetical by first tuple, etc.); Binary Large Object (BLOB); stored as ungrouped data elements encoded using ISO/IEC 7816-6 data elements; stored as ungrouped data elements encoded using ISO/IEC Abstract Syntax Notation (ASN.1) as in ISO/IEC 8824 and 8825; and/or other proprietary techniques that may include fractal compression methods, image compression methods, etc.

In one exemplary embodiment, the ability to store a wide variety of information in different formats is facilitated by storing the information as a BLOB. Thus, any binary information can be stored in a storage space associated with a data set. The BLOB method may store data sets as ungrouped data elements formatted as a block of binary via a fixed memory offset using one of fixed storage allocation, circular queue techniques, or best practices with respect to memory management (e.g., paged memory, least recently used, etc.). By using BLOB methods, the ability to store various data sets that have different formats facilitates the storage of data associated with the system by multiple and unrelated owners of the data sets. For example, a first data set which may be stored may be provided by a first party, a second data set which may be stored may be provided by an unrelated second party, and yet a third data set which may be stored, may be provided by an third party unrelated to the first and second party. Each of these three exemplary data sets may contain different information that is stored using different data storage formats and/or techniques. Further, each data set may contain subsets of data that also may be distinct from other subsets.

In one embodiment, the graphical user interface (GUI) module 110 may enable the FMEA analyst to facilitate an FMEA project associated with one or more components or process during the product development cycle. The GUI module 110 may enable the FMEA analysts to view a real time FMEA status through a user interface 112 provided by the GUI module 110. The real time FMEA status may enable the FMEA analysts to track a progress of the FMEA project. Further, the GUI module 110 displays one or more information pages, on the user interface 112, associated with a sequential order of elements essential to the FMEA project. The GUI module 110 may further enable to receive textual inputs, from the FMEA analysts, for the required information associated with the sequential order of elements. The sequential order elements are used to identify a potential effect and cause associated with a problem in functioning of the product, and further helps in eliminating the problem. The GUI module 110 may further enable the FMEA analysts to organize the sequential order of elements in a tree structure format, based on the information, received from the FMEA analyst, associated with the sequential order of elements. The tree structure enables the FMEA analyst to access the information pages associated with the sequential order of elements and update the information in real time during the product development cycle.

In an embodiment, the GUI module 110 develops one or more risk charts in the user interface 112 based on the information associated with the sequential order of elements. The risk chart enables the FMEA analyst to track a risk mitigation progress for the FMEA project during the product development cycle.

Referring to FIG. 2, an exemplary implementation of the GUI module 110 is depicted, according to an embodiment of the disclosure. As illustrated in FIG. 2, the GUI module 110 is may be deployed on the server 102 and is communicatively coupled to the repository 104, and the user device 106. In an embodiment, the GUI module 110 may enable the FMEA analysts to facilitate a FMEA project on the user interface 112. The GUI module 110 may include a display module 202, a receiving module 204, an organization module 206 and a developing module 208.

In operation, the display module 202 is configured to provide a path on the user interface 112 to create the FMEA project associated with one or more components or process steps during a product development cycle. The FMEA project may include a Design FMEA Project (DFMEA), a Process FMEA Project (PFMEA) or a validation project. The validation project may include a combination of multiple DFMEAs, PFMEAs or a combination of multiple DFMEAs and PFMEs. Moreover, the validation project may be formed by combination of multiple other validation projects.

In an embodiment, the FMEA project involves one or more team members (herein after referred to as FMEA analysts) for a completion of various tasks that may be associated with the sequential order of elements in the FMEA project. The FMEA analyst, who may have a team leader role, may create a new FMEA project through the GUI module 110. The display module 202 may provide a path to the FMEA analyst to create a new FMEA project. As illustrated in FIG. 3, the display module 202 may provide a user interface window 300 to enable the FMEA analyst to create the new FMEA project.

In one embodiment, the user interface window 300 may include a “+New” dropdown tab to select a project type, such as the DFMEA project, the PFMEA project or the validation project. As illustrated in FIG. 4, on selecting the project type, the display module 202 may provide a user interface window 400 for creating the selected type of the FMEA project. In an exemplary embodiment of the disclosure, the figures represent that the type of the project selected is a DFMEA project, however, it is apparent to a person who is ordinary skilled in the art that the type of project may include any of the DFMEA, the PFMEA or the validation Project and the selection shown in the figures do not limit the scope of the disclosure.

Further, the receiving module 204 may receive the required information from the FMEA analyst to successfully create the DFMEA project. As illustrated in FIG. 4, the required information may include basic Key information such as the title of the project, the Automotive Industry Action Group (AIAG) edition to be followed for the project, the type of FMEA, the part number, etc. In an embodiment, the part number may be imported from the repository 104 by clicking on the “+Add” tab.

Further, as illustrated in a user interface window 500 in FIG. 5, from “Additional Info” tab, the receiving module 204 may receive additional information, from the FMEA analyst, associated with the FMEA project. The additional information may include information such as the start date and other important dates associated with the FMEA project, FMEA case, whether the FMEA project is shared, hours of operation, notes etc.

Furthermore, from “Systems/Codes” tab, information associated with major system, system, subsystem, may be received from the FMEA analyst. Also, some organization specific codes about the systems and the components and item may also be received from the FMEA analyst.

On successfully receiving the required information from the FMEA analyst to create the new FMEA project, the GUI module 110, as illustrated in FIG. 6, may provide a user interface window 600 under “Properties” tab. The window 600 includes information related to the newly created FMEA project. The display module 202 also provides a “+Add Related” tab on the window 600 to link other projects related with the FMEA project. The other related projects may include New Product Introduction (NPI) project for developing new products and Continuous Product Improvement (CPI) projects that are used to solve existing problems in the product for which the FMEA project is being created.

Subsequently, as illustrated in the FIG. 7, the display module 202 may enable the FMEA analyst to navigate the FMEA project through a user interface window 700 under the “FMEA” tab. On selecting the “FMEA” tab, the FMEA analyst is able to view an “FMEA Navigator” 710 on the user interface 112 to view the one or more sequential order of elements under the FMEA project.

As illustrated in FIG. 8, the display module 202 may provide a user interface window 800, in the “Team” sub-tab under an “Overview” tab, to add one or more team members as FMEA analysts in the FMEA project. In an embodiment, the FMEA analyst that has created the new FMEA project is added as the team leader for the FMEA project by default. Subsequently, the team leader may add other team members by clicking on a “+Add Team Member” tab. The team members may be searched across the organization by their names or organizational IDs by clicking on “Find Team Member” tab. The team leader may further provide roles based access control to the team members. In one embodiment, the team leader may change a team member's role at any time. A team member may be assigned the validation role only if that team member has validation access. Different roles such as the role of a facilitator, a project coordinator etc., may be assigned to the team members.

As illustrated in FIG. 9, the display module 202 may enable the FMEA analysts to create a session for recording a date stamp of the session and the attendance of the FMEA analysts who has participated in the session. As illustrated in a user interface window 900, the FMEA analyst may click on the “Session” sub tab under “Overview” tab to record the details of every meeting or session held for the FMEA project. Further, the FMEA analyst who has initiated the session may enter details of the session such as the title of the session, the date stamp, maturity indicator that indicates the development level of the project, the duration of the session, notes, and the attendance of the team members etc. The FMEA analyst may also enter the revision level of the session if there is any update in the session information. For example, the revision level 1 indicates that the session is conducted for the first time, and any updates in the session may increment the revision value by 1. In an embodiment, an error message is displayed if any required field is left blank in the window. In various embodiments of the present disclosure, the FMEA analysts may edit the information associated with the session at any stage during the course of the FMEA project.

Once the FMEA project is created, the display module 202 may display one or more information pages associated with the sequential order of elements to the FMEA analysts, to enable the receiving module 204 to receive textual inputs for the sequential order of elements. In various embodiments of the disclosure, the sequential order of elements is based on the type of the FMEA project. However, FIGS. 10-33 represents the sequential order of elements for the DFMEA project, it is apparent to a person who is ordinary skilled in the art that the GUI module 110 is capable of creating and handling any type of projects such as the DFMEA, the PFMEA and the validation projects and the description related to the DFMEA project in the figures do not limit the scope of the disclosure.

In an embodiment, as illustrated in FIG. 10, the display module 202 may provide a path through the “FMEA Navigator” to access a user interface window 1000 to create an item for the DFMEA project. Within an existing DFMEA project window, the “FMEA Navigator” 710 may be displayed by selecting the “FMEA” tab. Further, on clicking a “+” sign on the FMEA Navigator, an information page is displayed to the FMEA analyst within the window 1000 for creating a “New Item”. Subsequently, the receiving module 204 may receive the key information about the item under the “Key Info” tab from the FMEA analyst. For example, the FMEA analyst may enter the Item name under the “Key Info” tab.

Further, as illustrated in FIG. 11, a plurality of additional information may be received from the FMEA analyst under the “Additional Info” tab. The display module 202 displays an information page on a user interface window 1100 to enable the receiving module 204 to receive the additional information associated with the item. The additional information may include, but not limited to, a part number of the item. In one embodiment, the item part number may be imported from the repository 104. On clicking the “+Add” button on the window 1100, the display module 202 may display the existing organization part number for the item. In one embodiment, the FMEA analyst may add more than one part number to the item. As will be understood by a person skilled in the art, an error message is displayed to the FMEA analyst every time when there is any required field that is left blank. Also, if the entered part number for the item already exists in any other DFMEA project, then also an error message is displayed, and the data may not be saved until the error is corrected.

In various embodiments of the present disclosure, the information provided by the FMEA analyst for the item is editable. As illustrated in FIG. 12, the display module 202 provides an “Edit Item” tab on a user interface window 1200 to edit the information associated with the item. Also, the display module 202 updates the “FMEA Navigator” 710 to display the added item name under the FMEA project title. In an embodiment, the organization module 206 adds the item name in a tree structure format under the FMEA Project title in the “FMEA Navigator” 710, as illustrated in the user interface window 1200.

In an embodiment, as illustrated in FIG. 13, the display module 202 provides a user interface window 1300 for providing one or more requirements associated with the item. The user interface window 1300 may be accessed by selecting the item on the “FMEA Navigator” 710 and then selecting the “+Add Requirement” tab. On selection of the “+Add Requirement” tab, the display module 202 opens an information page to enable the receiving module 204 to receive textual inputs, from the FMEA analyst, for the one or more requirements associated with the item. In one embodiment, the FMEA analyst may enter the requirement name and description associated with the requirement, and click on the “OK” button. The FMEA analyst may further provide the additional information by selecting the “Additional Info” tab on the window 1300. In an embodiment, as the FMEA analyst clicks on the “OK” button, the organization module 206 adds the requirement in a tree structure format under the item name on the “FMEA Navigator” 710 as illustrated in FIG. 14.

In various embodiment of the present disclosure, the FMEA analyst may at any time edit the requirement by clicking on an “Edit Requirement” tab, and enter the updated information about the requirement. As will be understood by a person ordinary skilled in the art, a particular item within the FMEA project may have multiple requirements that may be defined in a similar manner as described above. Also, all the requirements associated with the item may show up under the item in a tree structure format.

Subsequently, as illustrated in FIG. 14, the display module 202 may provide a user interface window 1400, to add one or more potential failure modes associated with the requirement. The potential failure mode indicates a condition of inability of an item to perform a desired function in a desired manner. The user interface window 1400 may be accessed by selecting the requirement on the “FMEA Navigator” 710 and then selecting the “+Add Failure Mode” tab, which provides an information page in the user interface window 1400. Subsequently, the receiving module 204 may receive the key information about the failure mode under “Key Info” tab from the FMEA analyst. For example, the FMEA analyst may enter the name of the failure mode and the description associated with the failure mode. Further, the FMEA analyst may also add the NPI/CPI issues to the failure mode if required. The NPI/CPI issues may be stored in external databases and may be imported from the external databases by selecting the “Add NPI/CPI Issues” tab on the user interface window 1400. It will be understood that the description for adding a failure mode is explained with respect to a single failure mode; however, there may be more than one failure mode associated with a single requirement of an item.

Subsequently, as illustrated in the FIG. 15, the FMEA analyst may also enter a plurality of additional information, in a user interface window 1500, about the failure mode under the “Additional Info” tab. The additional information may include a problem description (PD) category and PD code. A PD code is a two digit code that describes a failure. For example, there may be different codes for different failure modes such as “Accident or Abuse”, “Vibrates/Shakes”, “Smokes Excessively”, etc. Further, a PD category may be defined as a category of similar PD codes. For example, “System Malfunction” may be a PD category that includes a plurality of PD codes corresponding to different failure modes. In one embodiment, the FMEA analyst may select a desired PD category from a list of predefined categories. In a further embodiment, a list of predefined PD codes may also be presented to the FMEA analyst to facilitate selection of the desired PD code for the failure mode.

In an embodiment, as the FMEA analyst clicks on the “OK” button in the user interface window 1500, the organization module 206 adds the failure mode in the tree structure format under the requirement on the “FMEA Navigator” 710 as illustrated in FIG. 16. In one embodiment, a specific symbol such as, a “*” symbol, may be added next to the failure mode icon on the tree structure provided under the “FMEA Navigator” 710 to indicate that one or more NPI/CPI issues are associated with the failure mode.

In a further embodiment, the FMEA analyst may also edit the failure mode by selecting the requirement from the “FMEA Navigator” 710, clicking on the Failure Modes tab, and double clicking the failure that needs to be edited. This provides the failure mode information page in an editable format, as shown in a user interface window 1600. The FMEA analyst may subsequently edit the information provided under the “Key Info” tab and the “Additional Info” tab associated with the failure mode. In one embodiment, the FMEA analyst may also remove the PD category and the PD code. For example, the PD code is automatically removed on removing the PD category. In one embodiment, a warning message may be displayed to the FMEA analyst to confirm the deletion of the PD category and the PD code. Further, the FMEA analyst may also edit the NPI/CPI issues associated with the failure mode, by either removing the associated issues or by adding new issues by importing them from the repository.

Subsequently, as illustrated in FIG. 17, the display module 202 may provide a user interface window 1700, to add one or more potential effect of failures associated with the potential failure modes. The potential effect indicates a potential outcome of a failure mode as perceived by a customer. The user interface window 1700 may be accessed by selecting the “Failure Mode” on the “FMEA Navigator” 710 and then selecting the “+Add Effect” tab, which provides an information page in the user interface window 1700. Subsequently, the FMEA analyst may select “Create A New Effect” tab to enable the receiving module 204 to receive the textual inputs, from the FMEA analyst, for the information associated with the potential effect of failure. The information may include the name of the effect, the description of the effect and an initial severity value associated with the effect. In one embodiment, the initial severity value is a ranking of the effect based on its severity. In various embodiments of the disclosure, the ranking may be pre-defined according to an organization standard. In an alternate embodiment, the initial severity value may be assigned based on a well-known industry standard such as an AIAG (Automotive Industry Action Group) standard. In one embodiment, the initial severity value may be imported from an external database or the repository 104, and the FMEA analyst may select the initial severity value by selecting the “Choose” button and double clicking on the severity ranking to select that severity value. In an alternate embodiment, in order to keep the severity value consistent throughout the project, the FMEA analyst may select an existing effect that is used in other failure modes within the same FMEA project. On adding the effect, the organization module 206 displays the potential effect of failure in a tree structure format added under the potential mode of failure in the “FMEA Navigator” 710, as illustrated in FIG. 18.

In a further embodiment, the FMEA analyst may also delete the effect from the failure mode by clicking on a minus (−) sign displayed besides the “+” sign on the “FMEA Navigator” 710. In one embodiment, a confirmation window is popped up to facilitate the FMEA analyst to confirm the deletion of the effect from the failure mode.

Subsequently, as illustrated in FIG. 18, the display module 202 may provide a user interface window 1800, to add one or more potential cause of failures associated with the potential mode of failure. The cause is defined as a condition that induces a failure mode. The user interface window 1800 may be accessed by selecting the “Failure Mode” on the “FMEA Navigator” 710 and then selecting the “+Add Cause” tab, which subsequently provides an information page in the user interface window 1800. This enables the receiving module 204 to receive textual inputs, from the FMEA analyst, for information associated with the potential cause of failure. The FMEA analyst may enter the name of the cause, the description of the cause along with important notes and an initial occurrence value associated with the cause under the “Key Info” tab in the user interface window 1800. In one embodiment, the initial occurrence value indicates the likelihood that the cause will actually happen. The occurrence value may be pre-defined in an external database or the repository 104 according to an organizational standard or a well-known industry standard such as the AIAG standard.

Further, as illustrated in the FIG. 19, the FMEA analyst may enter the additional information associated with the potential cause of the failure, in the user interface window 1900 under the “Additional Info” tab. The additional information associated with the potential cause of failure may include a mechanism of failure, a classification code, a part number and a part name. The mechanism of failure is a physical, chemical, electrical, thermal, or other type of process that results in a failure mode. Further, the causes may be classified under different categories and these classification categories may be assigned a code referred to as the classification code. The part number may be a standard organizational format number for the part of the product such as a bolt that has failed due the cause of the failure. Further, the FMEA analyst may also enter the additional Part name for the cause. In one embodiment, the part name may be stored in an external database or repository, and the FMEA analyst may search the part name by importing the list of part names from the database and selecting the desired part name for the cause. For example, by clicking on a “Find” button next to the part name displayed on the interface, a “Part Name Search” information page pops up. Subsequently, the FMEA analyst may select the type of part from a drop down list. Further, the FMEA analyst may search using a keyword, a list of available part names. Furthermore, the desired Part Name may be selected from the list and the selected Part Name is added under the “Additional Info” tab in the user interface window 1900. Subsequent to the completion of the information page in the user interface window 1900, the organization module 206 displays the cause in a tree structure format under the failure mode in the “FMEA Navigator” 710, as illustrated in FIG. 21.

In a further embodiment, the FMEA analyst may also edit the information added for the cause by clicking on an “Edit Cause” tab subsequent to selecting the potential cause from the tree structure on the “FMEA Navigator” 710.

In various embodiment of the present disclosure, every failure mode may have multiple effects and every effect may have multiple causes. Therefore, it shall be understood that there may be multiple combinations of causes and the effects for every failure mode associated with the requirement of every item in the DFMEA project.

In an embodiment, subsequent to enter the potential cause and potential effect for the potential failure mode associated with the requirement, the receiving module 204 may receive, from the FMEA analyst, information associated with a plurality of prevention and detection controls for every cause and effect combination. In one embodiment, for every combination of the potential cause and the corresponding potential effect, if a correlation of the initial occurrence value of the cause and the initial severity value of the effect is greater than a predetermined threshold, then one or more detection and prevention controls may be recommended for that potential cause and potential effect combination.

As will be understood, a detection control reflects how well a test or series of tests may find a design flaw; i.e. detect that a failure mode has happened or detect the presence of a cause. These are the controls that detect a defect that already exists. However, the detection control does not alter the initial occurrence value. As will be understood by a person skilled in the art, the detection controls identify a detection value that indicates the likelihood that a cause will actually happen. The detection value if defined within a range from 1 to 10, 1 being the lowest likelihood and 10 being the highest likelihood. In one embodiment, the detection controls may be predefined and stored in a database where standards work instructions, working tools and other standard instructions of an organization may be stored. For example, the detection controls may be stored in the repository 104.

Further, the prevention controls are the controls that are specifically related to the reduction or elimination of a cause. These are the controls that prevent a defect from being made. In one embodiment, the prevention controls can reduce occurrence value associated with the cause. For example, the FMEA analyst may add a prevention control for controlling a cause of failure by reducing the occurrence value associated with the cause. In one embodiment, the prevention controls may also be predefined and stored in a separate database within the organization.

In one embodiment, the FMEA analyst may add a plurality of detection controls and prevention controls for various failure modes, their associated causes and effects. For example, the FMEA analyst may add a pick list of detection and prevention controls to the FMEA project that may be used in the project at any later stage. The detection controls and the prevention controls may be generic in nature that may be implemented for multiple combinations of causes and effects. In one embodiment, the FMEA analyst may import the detection controls as well as the prevention controls from excel spreadsheet, various databases external to the system etc.

As illustrated in FIG. 20, the display module 202 provides a user interface window 2000 to select one or more controls for the combination of cause and effects. The FMEA analyst may access the window 2000 by selecting a “Controls Pick List” sub tab under the “Overview” tab on the user interface 112. Subsequently, the FMEA analyst may click on the “Edit Pick List” sub tab which provides an information page including a combination of elements. Further, the FMEA analyst may select the desired combination of elements for which the detection controls and prevention controls are required. Subsequent to the selection of the combination by the FMEA analyst, a complete list of detection controls available for that combination is displayed to the FMEA analyst. Further, the FMEA analyst may refine the list by selecting the appropriate detection controls as desired. In one embodiment, the FMEA analyst may click the check boxes next to the detection controls in the list. In a further embodiment, detection control list may include a test id and a description field. The test id indicates the unique identification number that may be specific to the organizational formats. In a further embodiment, the description indicates the description of the detection control test to be performed.

Subsequently, the FMEA analyst may add the prevention controls to the initial pick list by clicking on a “Next” button after adding the detection controls. In one embodiment, the FMEA analyst may import the prevention controls from external databases or repository 104. As will be understood, the FMEA analyst may add the prevention controls at any point in time during the FMEA project. All the prevention controls that are already associated with the project are listed on the list at the top with a different color background in the initial pick list. In one embodiment, the FMEA analyst may search for a keyword to get the entire list of prevention controls available for the keyword. For example, the keyword may be the name or part of the name of the item or failure mode etc. Subsequently, the FMEA analyst may select the required prevention controls for the case by clicking on the check boxes besides the controls. Further, the detection and the prevention controls selected by the FMEA analyst may be listed in the initial pick list and associated with the project.

In one embodiment, the FMEA analyst may import the detection controls and the prevention controls from any other FMEA project as well. In a further embodiment, the FMEA analyst may also edit the pick list to include additional detection and prevention controls, or removing the detection and the prevention controls. In a yet another embodiment, the FMEA analyst may also create new detection and prevention controls.

In one embodiment, the FMEA analyst may add a specific detection control from the initial pick list created by the FMEA analyst. In another embodiment, the FMEA analyst may create a new detection control in case when the desired detection control is not included in the initial pick list.

As illustrated in FIG. 21, the display module 202 provides a user interface window 2100, to add detection controls associated with the potential cause. The FMEA analyst may access the user interface window 2100 by selecting the “Cause” in the “FMEA Navigator” 710 and then selecting “Add Control/RA” tab.

Further, the FMEA analyst may select “Detection Control” from the drop down under the “Add Control/RA” tab and subsequently, a “New Detection Control” information page opens in a user interface window 2200, as illustrated in the FIG. 22. Subsequently, the FMEA analyst may select “Select From Pick List” tab and an “Initial Control Pick List” tab. Subsequently, the entire pick list of the detection controls is displayed with the Test id and the test description. The receiving module 204 may then receive the textual inputs, from the FMEA analyst, associated with required information to be filled in the “New Detection Control” information page on the user interface window 2200. For example, the required information may include the initial control, control name, procedure process, Test ID, associated with, information under “Key Info” and “Additional Info” tab etc. The information associated with the detection control may include a detection value that may be entered by the FMEA analyst for that control. In one embodiment, the detection value may be selected from a list of predefined values stored in external databases or repository 104.

In an embodiment, the FMEA analyst may also add some general category detection controls that may not be already included in the initial pick list. The FMEA analyst may add the general detection control by selecting the “Cause” in the “FMEA Navigator” 710 and then selecting “Add Control/RA” tab.

Further, the FMEA analyst may select “Detection Control” from the drop down under the “Add Control/RA” tab and subsequently, a “New Detection Control” information page opens, where the FMEA analyst may select the “Create A Control” tab. Further, the FMEA analyst may enter the control name. In one embodiment, the Test Id field may indicate the detection control to be “General” category detection control. The FMEA analyst may further associate the detection control with a failure mode or a cause of the failure mode, as desired. In a further embodiment, the FMEA analyst may add the other information about the control and subsequently add the detection control to the FMEA project. For example, the information may include the test plan procedure, the test id, test purpose, the type of test, test classification, the acceptance criteria etc. As will be understood, if the detection control is added to a failure mode, then by default all the causes related to the failure mode may have access to that detection control.

In a further embodiment, the detection control may be edited by the FMEA analyst at any point of time with the FMEA project. In one embodiment, the added detection control must be approved by a validation engineer in case of a DFMEA project. However, in an alternate embodiment, a team leader's approval is required for every created detection control in case of a PFMEA project. In one embodiment, only an Admin person or the approving person may be authorized to change the approval status of a detection control. In an alternate embodiment, the validation engineer and the team leader may reject the detection control if desired. In a further embodiment, the date and time stamps of the approval of the detection control may be viewed on the interface 112. Subsequent to the approval of the detection control, the results for the detection control may be edited to include the desired results for every detection control test procedure.

Subsequent to the successful completion of creation of the detection control, the organization module 206 displays the detection control in a tree structure format under the cause on the “FMEA Navigator” 710, as illustrated in a user interface window 2300 of FIG. 23. Further, the user interface window 2300 also provides the information such as, associated cause, detection control information, Test Id, detection value, responsible FMEA analyst, occurrence value, etc.

In a further embodiment, the FMEA analyst may also delete a desired detection control. For example, the FMEA analyst may highlight the desired detection control and click on the minus (−) sign next to the “+” sign on the “FMEA Navigator” 710. In one embodiment, the FMEA analyst may be presented with a confirmation message to delete the selected detection control.

Subsequent to adding the detection controls, the FMEA analyst may also add a plurality of prevention controls to the failure modes and the associated causes. In one embodiment, the FMEA analyst may add a prevention control from the initial pick list or create a new prevention control, if the desired prevention control is not included in the initial pick list.

As illustrated in the FIG. 24, the display module 202 provides a user interface window 2400, for adding one or more prevention controls. In an embodiment, the FMEA analyst may select a “Cause” in the “FMEA Navigator” 710 and subsequently select “Add Control/RA” tab to open a “New Prevention Control” information page as illustrated in the user interface window 2400. Further, the FMEA analyst may click on “Select From Pick List” tab that displays a list of prevention controls from the initial pick list. Further, the FMEA analyst may select the prevention control from the list of available controls and click “OK”. In one embodiment, the FMEA analyst may add information about the prevention control. For example, the information may include the prevention control description, document ID and date fields. In one embodiment, the FMEA analyst may also enter key information about the prevention control, such as the occurrence value, the forecast occurrence value, planned end date, description etc. The forecast occurrence value indicates the probable occurrence value of the cause after implementing the prevention control. In one embodiment, the forecast occurrence value may be imported from external databases or from repository 104.

In an alternate embodiment, the FMEA analyst may create a new general category prevention control, if the prevention control is not already included in the initial pick list. For example, with the FMEA open and the cause of failure highlighted in the “FMEA Navigator” 710, click on “+Add Control/RA” tab and select “Prevention Control” tab. Subsequently, the “New Prevention Control” information page opens, where the FMEA analyst may click the “Create A General Control” tab. Further, the FMEA analyst may enter the “Control Name”. In one embodiment, the Test ID field will say “General”. Furthermore, the FMEA analyst may enter test information under “Key Info” tab such as the “Associated With” field to be associated with either a failure mode or cause, the description of the prevention control, planned end date etc.

Subsequent to adding all the required information, the organization module 206 displays the prevention control in a tree structure format under the “Cause” on the “FMEA Navigator” 710, as illustrated in a user interface window 2500 of FIG. 25. Further, the user interface window 2500 also provides the information such as, associated cause, detection control information, Test Id, detection value, responsible FMEA analyst, occurrence value, etc.

In a further embodiment, the FMEA analyst may also edit the prevention control at any point of time during the FMEA project. In a further embodiment, the FMEA analyst may also define the team member responsible for executing the test plan of the prevention control. In a further embodiment, the prevention control may be approved only by a team leader of the project. As will be understood, the team leader may approve every prevention control created for every failure mode and cause. In an alternate embodiment, the team leader may also reject the prevention control. If the team leader approves the control, then a date and time stamp associated with the approval is displayed on the window. In a yet another embodiment, the FMEA analyst may delete the prevention control in a similar manner as described for deletion of the detection control from the FMEA project.

Subsequent to adding a plurality of detection and prevention controls, the display module 202 may enable the FMEA analyst to add a plurality of recommended actions. The recommended actions are the actions taken to mitigate risk associated with the cause and effect combination. There are two types of recommended actions: “gather data” and “change design” for a DFMEA project. In an embodiment, if the correlation of the severity value and the occurrence value associated with a cause/effect combination is higher than a predetermined threshold to indicate the combination a high risk combination, then a recommended action may be executed. In a yet another embodiment, if the correlation of the severity and occurrence value associated with a cause/effect combination is lower than the predetermined threshold to indicate a probable risk associated, however, a correlation of the severity, occurrence and the detection value that is a risk priority number (RPN) associated with the cause/effect combination is higher than a second predetermined threshold, say 100, then a recommended action may be associated with the combination of the cause and the effect. The RPN value is a product of the severity value of the effect, the occurrence value of the cause and the detection value of the cause. At the time of evaluating the RPN value, the RPN value is referred to as an initial RPN value using the initial severity, initial occurrence and initial detection value associated with the cause/effect combination. In an embodiment, the initial RPN value may change based an execution of the prevention control as it may revise the initial occurrence value.

In one embodiment, the recommended actions that result in a design change or new design features are referred to as the “Change Design” recommended action. These can either eliminate the possibility of the failure mode or reduce the occurrence of the failure. In a further embodiment, the type of recommended action used in a DFMEA project when there is not enough data to know about the potential risk, then these recommended actions are referred to as the Gather Data type recommended actions.

In one embodiment, whenever changes are required to be made to the design of the item, a “change design type” recommended action is required. This captures the whole description of the change and also how that change will be verified.

As illustrated in FIG. 26, the display module 202 provides a user interface window 2600, for adding one or more recommended actions. The FMEA analyst may access the user interface window 2600 by selecting the “Cause” in the “FMEA Navigator” 710 and subsequently selecting “Recommended Action” from the “Add Control/RA” tab.

Subsequently, a “New Recommended Action” information page opens in a user interface window 2700, as illustrated in FIG. 27. Further, the FMEA analyst may select the type of the recommended action. In one embodiment, the FMEA analyst may select “Change Design” type of the recommended action.

Further, as illustrated in a user interface window 2800 in FIG. 28, the FMEA analyst may enter the required information such as the title of the action and the information in “Key Info” under the “Test Plan” tab. The information may include the association of action (with failure or cause), forecast values of severity, occurrence, detection, the team member responsible for execution of the action, required target date, the description. The forecast values indicate the probable values after completion of the recommended actions. In an embodiment, the forecast values associated with the recommended actions may be predefined and stored in an external database, and may be imported by clicking the “Choose” button. The values of the forecast severity, occurrence and detection may be based on the AIAG edition implemented in the GUI module 110.

Further, as illustrated in FIG. 29, the FMEA analyst may enter the additional information in a user interface window 2900, under the “Additional Info” for the “TEST PLAN” tab. The additional info may include test purpose, type of result, acceptance criteria, test environment, classification of test, type of test, type of machine, any suggestion to modify the test, expected planned product, planned test location etc. Additionally, the FMEA analyst may enter the planned start date, planned end date, planned duration, notes etc., of the action.

Subsequently, as illustrated in FIG. 30, the FMEA analyst may enter the additional information, in a user interface window 3000, in “Key Info” under a “Change Design” tab. The information may include the team member assigned the task, the target date, completion date, the description of the changed design. Further, as illustrated in FIG. 31, the FMEA analyst may enter in the “Additional Information” in a user interface window 3100 under the “Change Design” tab. The information may include a description related to the action taken by the team member. As will be understood by a person skilled in the art, the FMEA analyst may also create a new recommended action for “gather data” type, in a similar manner as described above.

In an embodiment, the FMEA analyst may add a recommended action of “Action type” when there is no design change and there is enough information available to know about the potential risk. These “Action Type” actions may also be added to the FMEA project in a similar manner as explained above.

Subsequent to adding all the required information, the organization module 206 displays the recommended action in a tree structure format under the “Cause” on the “FMEA Navigator” 710, as illustrated in a user interface window 3200 of FIG. 32.

Further, the FMEA analyst may edit the recommended actions at any point of time during the FMEA project. The recommended actions may be edited by highlighting the recommended action and clicking on the “Edit Recommended Action” tab. Subsequently, an “Edit Recommended Action” page opens and the FMEA analyst may update the information associated with the recommended action. In one embodiment, the recommended actions may be approved by the team leader of the project. As will be understood by a person skilled in the art, every recommended action for every cause/effect combination may be approved by the team leader. On approval of the action, the date and time stamp may be viewed on the “Edit Recommended Action” window. In one embodiment, subsequent to the approval of the recommended action, the results associated with the recommended actions may be added. In an alternate embodiment, the team leader may reject the recommended action and the results tab may not be editable after rejection of the recommended action.

As illustrated in FIG. 33, the display module 202 provides a user interface window 3300, to the FMEA analyst under the “Results” tab to provide the information on an execution of the recommended action by the responsible FMEA analyst. The information may include a test status, a validation status, an actual severity, an actual occurrence, an actual detection, name of the FMEA analyst that executed the action, and the actual end date. In an embodiment, the actual severity, occurrence and detection may be selected based on an industry standard definition and may be selected based on pre-defined values stored in an external database or in repository 104.

In further embodiments, as illustrated in FIG. 34, the display module 202 may provide a user interface window 2700, to add product information for the FMEA project. The user interface window 3400 may be accessed by selecting the “Product” sub tab under the “Overview tab. Subsequently, the FMEA analyst may select the “Edit Selections” tab. Further, the FMEA analyst may enter information about the product such as the product types, product family, the sales mode, the serial number of the product, the manufacturing facilities etc. In one embodiment, the FMEA analyst may use arrow keys to select or deselect an option. In one embodiment, the product information may be predefined and stored in an external database. The entire list may be imported from the database to select the desired information. In a further embodiment, the FMEA analyst may add multiple options for every field.

In an embodiment, the FMEA analyst may also add related FMEA projects, NPI and CPI projects and other similar projects to the current FMEA project. A list of related FMEA projects may be imported from an external database and displayed, wherein the FMEA analyst may select the desired project to be added to the current FMEA project. In one embodiment, the FMEA projects listed may include various fields such as the test ID, the Project title, type of project, maturity indicator that indicates whether the project is completed or pending or under development status.

In a further embodiment, the FMEA analyst may add related NPI projects or CPI projects to the FMEA project. In a yet further embodiment, the FMEA analyst may also add other related internal projects within an organization in a similar manner as described above.

In an embodiment, the FMEA analyst may add a one or more attachments that may be used for the sequential order element in the FMEA project at any point in time. For example, an attachment may be any document or a presentation etc. that may be required for an element in the FMEA project. For example, the FMEA analyst may click on an “Attachment” tab and subsequently click on an “Upload Attachment” sub tab. Further, an “Add Attachment” pop up information page opens up. Subsequently, by clicking on a “+” sign, the FMEA analyst may add an attachment from a local or a shared drive. Similarly, an attachment may also be removed by clicking on a minus (−) sign displayed besides the attachment in the “Attachment” tab. In a further embodiment, the FMEA analyst may download the attachment; edit the details of the attachment etc. In a yet another embodiment, the FMEA analyst may also add hyperlinks, notes, or any other characteristics that may be used as a additional information related to any element of the sequential order in the FMEA project.

In an embodiment, the GUI module 110 provides a real time FMEA status, associated with the FMEA project, through the “Summary” Tab. In an embodiment, the FMEA analyst may view more than one projects assigned to him under the “Summary” tab. For example, a single team member may be a team leader for one project, may be responsible for validation of detection controls in another project and so on. Therefore, the FMEA analyst may get a list of all the projects assigned, on logging on to the system by using appropriate credentials. For example, there may be a “My FMEA Projects” tab that lists all the projects assigned to the FMEA analyst.

In one embodiment, the FMEA analyst may login to the user interface 112 and click on the “My FMEA Projects” tab, to view a particular FMEA project details. Further, the FMEA analyst may search the entire “My FMEA Projects” list by using a keyword search. Further, the FMEA analyst may select the desired FMEA project, and subsequently click on the “Summary” tab of the project to view the details of the project.

As illustrated in FIG. 35, in a user interface window 3500, the “Summary” tab may indicate a tabular form of data related to the FMEA project. In one embodiment, the FMEA form within the “Summary” tab may include the plurality of sequential elements that are added for the FMEA project as explained above. For example, the summary table may include the item name, the requirements associated with items, the failure modes associated with the requirements, the causes, the effects, the initial occurrence value of the cause, the initial severity value of the effect, the initial detection value associated with the cause, and an initial RPN value associated with every cause effect combination. In a further embodiment, the table may also include the controls listed for those cause/effect combination and the type of control such as a prevention control or a detection control. In a further embodiment, the summary table may be updated in real time. For example, as soon as a change occurs in any information, i.e., an FMEA analyst enters the current value of the severity, occurrence, detection value and the resultant RPN value etc., the summary table reflects the updated information immediately in real time. As will be understood, the real time update of the summary table facilitates the FMEA analyst to track the FMEA project in real time and required actions may be taken on an immediate basis.

In one embodiment, if there are multiple effects associated with a single cause, then for evaluating the RPN value, the effect with the highest severity is considered. For example, if for cause 1, there are four effects namely, effect 1 having initial severity value of 4, effect 2 having initial severity value 7, effect 3 having initial severity value of 2 and effect 4 having initial severity value of 3, then automatically the effect with the highest severity value, i.e., effect 2 in this case is selected to evaluate the RPN value for this cause/effect combination for an item. Ina further embodiment, if there is no initial detection value specified for a cause, then a default value may be taken for evaluating the initial RPN value. In an example, the initial default detection value may be defined specific to an organization, such as a value of 10 may be considered as the default detection value. As will be understood by a person skilled in the art, there may be multiple items and multiple cause/effect combination for each item in an FMEA project, therefore, there are RPN values associated with each cause/effect combination of each item. In one embodiment, the portion on the left side of the table from the RPN value is referred to as an initial view for the initial severity and occurrence values.

In a further embodiment, the summary table may also include other fields such as a recommended action to be implemented for a particular cause/effect combination, the team member responsible for executing the recommended action, the target date, the actual actions taken etc. Subsequent to the execution of the recommended actions, the actual or current severity value, occurrence value, detection value and the current RPN value may also be displayed in the summary view. As will be understood, the actual or current values of severity, occurrence, detection and RPN may be same or different than the forecasted values entered into the project while adding the recommended actions to the FMEA project as described earlier. For example, the recommended action may not be successful as expected and therefore may not reduce the occurrence and the severity value as expected or as forecasted by the team leader. In one embodiment, the right side of the table from the RPN value column may be referred to as a current view for the current severity and occurrence values.

In an embodiment, the summary report may be exported into an excel file by clicking on the “Export” button given on the “Summary” tab on the interface 112. In a still further embodiment, the summary table may indicate different symbols to indicate incomplete information about an element, an overdue task, a required recommended action for a specific cause, a linked related NPI/CPI issues etc. For example, a triangle displayed besides an element indicates that the element is not complete, i.e., all the required fields for that element are not filled. Similarly, a red flag displayed besides a cause or an effect indicates that a recommended action is required to be executed to eliminate the cause or the effect to lower or eliminate the risk associated. In a further embodiment, a clock symbol displayed besides a control or an action indicates that the action execution is overdue its desired target date. Furthermore, a “*” symbol displayed besides a failure mode may indicate linked related NPI/CPI issues.

In an embodiment, the FMEA analyst may hide the columns that may not be required at the time of analysis, by clicking on a “Toggle Columns” tab. Subsequent to clicking on the “Toggle Columns” tab, a list of all the columns in the table is displayed to the FMEA analyst, wherein the FMEA analyst may select the columns to hide and click on the “OK” button to save the settings. Subsequently, the FMEA analyst may again click on the “Toggle Columns” tab to get the list back and deselect the columns to view all the columns in the summary table.

As illustrated in FIG. 36, the FMEA analyst may also run status reports for a status check of controls and recommended actions pending in the FMEA project. In an embodiment, the FMEA analyst may click on the “Toggle Status Report” tab on the interface to view the overdue controls and recommended actions in a user interface window 3600. For example, the status report table may include the recommended action identifier, the description of the action, planned start date, planned end date, assigned to etc. In another embodiment, the team member responsible for executing the overdue controls and/or the recommended actions may be notified automatically through an email for executing the controls on an urgent basis.

In an embodiment, a notification message may be displayed on the top of the summary table as soon as the FMEA analyst clicks on the “Summary” tab, indicating that there are a one or more recommended actions and/or controls that are overdue their target date.

In a further embodiment, every cell of the summary table is clickable to facilitate the FMEA analyst to edit or add a new element and its information. For example, on double clicking on an element in a cell, the FMEA analyst is automatically redirected to the EDIT page of that element, where the FMEA analyst may edit the information about that element or create a new element. For example, if the FMEA analyst double clicks on a recommended action cell having a recommended action 1, then a pop-up window of “Edit Recommended Action” opens up, and subsequently the FMEA analyst may edit the information stored for that recommended action in a similar manner as described earlier in the description. Similarly, on double clicking any element in a cell of the summary table, the FMEA analyst may be redirected to the page for editing and adding a new element.

As illustrated in a user interface window 3700 in FIG. 37, the FMEA analyst may view all the projects and the tasks in addition to their timelines, target dates etc., by viewing a “My Actions” sub tab under the “My FMEA Projects” tab. Further, the FMEA analyst may receive reminders near a due date for a task assigned. For example, based on a target date or completion date for a prevention control execution, the FMEA analyst may be reminded automatically through an email that the prevention control execution is due on the specific target date.

In a further embodiment, the FMEA analyst may view a complete Design Verification Plan and Report (DVP&R) for the entire product or process by clicking on a “DVP&R” tab. A DVP&R may be defined as a method to plan and document testing activity through each phase of a product or a process development starting from the inception to the ongoing refinement of the project. In one embodiment, the FMEA analyst may monitor the entire project by viewing the DVP&R table under the “DVP&R” tab, as illustrated in a user interface window 3800 in FIG. 38.

In one embodiment, the DVP&R table may include the information related to the controls, the recommended actions, the responsible person, the target dates, the associated failure modes, the description of the controls and the recommended actions etc. For example, the FMEA analyst may view the status of execution of the controls and the recommended actions in the DVP&R table.

In one embodiment, an indication about incomplete controls and recommended actions by displaying a triangle besides the incomplete control and/or recommended action. Further, the FMEA analyst may double click on the control and/or the recommended action to subsequently open the “Edit Control” information page. Subsequently, the FMEA analyst may update the control and/or the recommended action by completing the required information. In a still further embodiment, the FMEA analyst may run a status report from the “DVP&R” tab by clicking on the “Toggle Status Report” tab and viewing and utilizing the status report in a similar manner as described above for the “Summary” tab. Additionally, the FMEA analyst may also hide the columns to be viewed in a similar manner as described above for the “Summary” tab, by clicking on the “Toggle Columns” tab on the interface. Additionally, the columns in the DVP&R table may be sorted alphabetically in order to facilitate the FMEA analyst to view the desired information. Further, the FMEA analyst may also export the DVP&R table into an excel file for future usage.

As illustrated in a user interface window 3900 in FIG. 39, the GUI module 110 may enable the FMEA analyst to sync and replace a plurality of FMEA projects in a validation project. For example, if two or more FMEA projects have a plurality of controls that may be common to these projects, then the controls for these projects may be synced. As will be understood by a person skilled in the art, only same types of controls may be synced together. For example, only a detection control may be synced with another detection control. Similarly, only a prevention control may be synced with another prevention control. In a further embodiment, if a synced control is completed for one project, then it may not be required to execute it repeatedly for all the other projects, however, it may be marked completed for every other project for which the control is synced. In a still further embodiment, for the synced controls, the FMEA analyst may edit only the common fields of the synced controls. However, a plurality of unique fields may not be editable for every synced control.

As illustrated in window 3900, the FMEA analyst may click on the “DVP&R” tab and subsequently select the controls and/or the recommended actions to sync, and further click a “SYNC” tab as illustrated in FIG. 39.

Subsequent to clicking on the “SYNC” tab, a “Sync” information page opens up that displays the selected controls and/or the recommended actions, as illustrated in a user interface window 4000, in FIG. 40. Further the FMEA analyst may select the entire master row shown in the window and subsequently, click “OK”. The selected controls are synced and only one row i.e. master row shows up in DVP&R table, as illustrated in a user interface window 4100, in FIG. 41.

In one embodiment, an email confirmation is sent out to the team leader(s) listing the information regarding synced controls. In a further embodiment, the FMEA analyst may select the master row and click “Single Test Report” tab on the interface 112 to view all the controls and their information that were synced. In a still further embodiment, the single test report may also be exported to an excel file for future references. In another embodiment, the FMEA analyst may also replace the synced controls and/or the recommended actions by selecting the control to be replaced and the control for replacing the previous control and subsequently clicking on the “Replace” button shown on the interface 112.

In an alternate embodiment, the FMEA analyst may add a process FMEA (PFMEA) project. As will be understood by a person skilled in the art, a PFMEA is an analytical technique used by a manufacturing-responsible engineer or a team of engineers as a means to assure that, a plurality of potential failure modes and their associated causes and effects have been considered and addressed to minimize the risk associated. In one embodiment, the PFMEA may be created, and the several sequential elements may be added, edited and viewed in a similar manner as described above for a DFMEA project.

Further, the PFMEA may include a process step, a plurality of desired outputs associated with every process step etc. For example, the functional requirements may be added to the PFMEA for every process step that indicate the desired output of a process step when performing the step normally. Further, a failure mode, a potential effect of the failure mode, potential cause of the failure mode may be added for every functional requirement and every process step of the PFMEA project. Similar to a DFMEA project, the PFMEA project may include a severity value for the effect of failure, an occurrence value associated with the cause of failure mode, a detection value for the cause of failure mode and an RPN value for every cause/effect combination in the PFMEA project. In a further embodiment, the prevention controls, detection controls and the recommended actions may be added and implemented in a similar manner as done for a DFMEA project. In one embodiment, the detection controls and the prevention controls may include a prototype that may be imported from external database or the repository 104.

In one embodiment, the developing module 208 develops a risk chart for the FMEA project associated with the sequential order of elements, explained above, during the product development cycle. The risk chart enables the FMEA analysts to track a risk mitigation process for the FMEA project through the product development cycle. In an embodiment, the developing module 208 is adapted to develop a risk chart for a single FMEA project or for a validation project that includes multiple FMEA projects.

The developing module 208 may develop two types of charts, namely a Criticality Matrix Risk Chart (CMRC) and a Proactive Reliability Risk Chart (PRRC). However, it will be understood by a person skilled in the art, the number of charts and the type of charts are exemplary and may be extended to include similar functionalities.

In one embodiment, a CMRC may be used to visually present a criticality of potential failure modes and the risks associated with those failures. The CMRC is based on a correlation of severity values associated with potential effects of failure, and occurrence values associated with potential causes of failures.

As illustrated in user interface window 4200 of FIG. 42, the CMRC is formed as a grid which is divided in three different zones: a risk mitigation zone 4210, a probable risk mitigation zone 4220 and a risk free zone 4230. The CMRC is divided in the three zones 4210, 4220, and 4230 based on the severity and occurrence values for each combination of cause and effect in the FMEA project or the validation project.

As illustrated in FIG. 42, the occurrence values are plotted on an X-axis of the grid and the severity values are plotted on a Y-axis of the grid. Each cell with in the grid includes a total number of cause and effect combinations from the FMEA project corresponding to the occurrence and severity values plotted in the CMRC. For example, consider a cell in the grid at the position of severity value 8 and occurrence value 1, then the value entered in this cell, say 48, indicates that there are 48 unique cause and effect combination in the FMEA project that have severity value of 8 and occurrence value of 1. Similarly, absence of any value in a grid cell indicates there is no such cause and effect combination corresponding to those severity and occurrence values.

In an embodiment, the three zones 4210, 4220, and 4230 in the grid may be populated based on industry standards, such as an AIAG standard. However, it will be appreciated that the grid may be updated to adapt with updates in the industry standards.

In an embodiment, the risk mitigation zone 4210 includes all such combination of potential causes of failure and potential effects of failure that have a correlation of the severity value and the occurrence value greater than a predetermined threshold. The threshold value may be based on the AIAG standard. Each of the cause and effect combinations in the risk mitigation zone may include one or more recommended actions from the FMEA analyst to mitigate the risk associate with those cause and effect combinations. The criticality of the risk associated with a cause/effect combination is based on the severity value and the occurrence value of the effect and the cause respectively.

In an embodiment, the probable risk mitigation zone 4220 includes all such combination of potential causes of failures and potential effects of failure that have a correlation of the severity value and the occurrence value greater than a predetermined threshold. The threshold value may be based on the AIAG standard. Each of the cause and effect combinations in the probable risk mitigation zone 4220 may include one or more controls such as prevention controls or detection controls. Further, in an embodiment, if any combination of potential causes of failure and potential effects of failure in the probable risk mitigation zone 4220 has an RPN value greater than a pre-determined value, then all those combinations have one or more recommended actions. The RPN is based on a correlation between the severity value, the occurrence value and the detection value. The detection value is associated with each combination of the potential causes of failure and the potential effects of failure. In an embodiment, the detection value is taken as a predetermined number to calculate the RPN if no inputs are provided by the FMEA analyst for the detection value.

In an embodiment, the risk free zone 4230 includes all such combination potential causes of failure and potential effects of failure that have a correlation of the severity value and the occurrence value lesser than a predetermined threshold. The threshold value may be based on the AIAG standard. Each of the cause and effect combinations in the risk free zone 4230 may not need any controls or recommended actions.

In various embodiments, the three zones 4210, 4220 and 4230 may be visually separated from each other by color codes, a hatch pattern or the like. However, it will be apparent to a person skilled in the art that the three zones may be visually separated by using any other method known in the art.

In an embodiment, the CMRC may include an initial CMRC, forecast CMRC and a current CMRC. As illustrated in user interface window 4300 of FIG. 43, the FMEA analyst may track a progress of the risk mitigation in the FMEA project by comparing the initial CMRC and the current CMRC. The display module 202 may provide the user interface window 4300 under the “Reports” tab for the selected FMEA or validation project. The initial CMRC is based on an initial severity value and an initial occurrence value associated with a combination of at least one potential cause of failure and at least one potential effect of failure. In an embodiment, the initial CMRC may be revised based on an initial occurrence value associated with the combination of the at least one potential cause of failure and the at least one potential effect of failure. The initial occurrence value is revised based on an execution of at least one prevention control associated with the combination of the at least one potential cause of failure and the at least one potential effect of failure. Further, the current CMRC is based on a current severity value, and a current occurrence value associated with a combination of at least one potential cause of failure and at least one potential effect of failure. The current severity value and the current occurrence value is based on an execution of at least one recommended action associated with the combination of the at least one potential cause of failure and the at least one potential effect of failure. Further, the forecast CMRC is based on a forecast severity value, and a forecast occurrence value associated with a combination of at least one potential cause of failure and at least one potential effect of failure. The forecast severity value and the forecast occurrence value is based on a presumption execution of at least one recommended action associated with the combination of the at least one potential cause of failure and the at least one potential effect of failure.

As illustrated in FIG. 44, the developing module 110 may enable the FMEA analysts to view a report from the risk chart. The FMEA analyst may select any cell within the CMRC to view information associated with all the combinations of cause and effect under that cell and other sequential order of elements associated with that combination, as illustrated in user interface window 4400. The information may include one or more of an item, or process step, requirements associated with item or process step output, potential failure modes associated with the item or process, an initial severity value, an initial occurrence value and an initial detection value associated with the combination cause and effects, prevention or detection controls associated with the combination cause and effects, a validation identification of the FMEA project, recommended actions associated with the combination of the cause and effects, of failure, a forecasted severity value, a forecasted occurrence value and a forecasted detection value associated with the combination of the cause and effects, a current severity value, a current occurrence value and a current detection value associated with the combination of the cause and effects, the FMEA analysts assigned for an execution of the one or more prevention or detection controls and the recommended actions, and a start date, target completion state associated with the prevention or detection controls and the recommended actions. In an embodiment, the sequential order of elements in the report may also include visual descriptors associated with the elements. The visual descriptors provide a status or issues associated with the elements.

In an embodiment, the display module 202 provides a path in the report to view and edit the information associated with the elements of the sequential order of elements. In an embodiment, the FMEA analyst may select any element in the report and may double click that to view the edit information page corresponding to that element. For example, the FMEA analyst may want to revise the initial occurrence value for a combination of cause and effect and thus double click the corresponding cell under the initial occurrence column to view the edit cause information page. In an embodiment, the display module 202 may provide a path on the report to export the report in XML format or any other required format known in the art In an embodiment of the disclosure, the PRRC is based on a timeline for risk mitigation during the FMEA project and a Dealer Repair Frequency (DRF). The DRF is a correlation of an occurrence value and an ability to predict that occurrence after the validation. The calculation of DRF is done for each failure mode and cause combination in the FMEA project. Specifically, the PRRC is based on the timeline for risk mitigation and a mean DRF. The mean DRF is a failure rate spread for a limited time-period in a product lifecycle.

As illustrated in a user interface window 4500 in FIG. 45, the PRRC is plotted between a mean DRF and the timeline for risk mitigation. The PRRC further includes a design DRF, a glide-path DRF, a capability DRF, a target DRF, a current DRF, a history DRF, a carryover DRF and a projection DRF. The PRRC is developed either for a single FMEA project or for a validation project or for a combination of validation projects.

The target DRF is based on a specified target timeline provided by the one or more FMEA analysts for the risk mitigation. The target DRF is provided by the one or more FMEA analysts on the user interface. As illustrated in a user interface window 4600 in FIG. 46, a target DRF may be provided, by the FMEA analyst, for the FMEA project in the “Coverage table” under the “Overview” tab. Similarly, as illustrated in a user interface window 4700 in FIG. 47, a target DRF may be provided for a validation project. Also, a carryover/block load DRF is also provided for adding NPI/CPI DRF values if the same is not included in the individual FMEA projects. Further, as illustrated in the user interface window 4700, system, subsystem may be selected and provided by the FMEA analyst. The user interface window 4700 also displays the various FMEA or validation projects associated with the PRRC.

In an embodiment, when an initial DRF calculation is performed using an initial occurrence value within the FMEA project, it is termed as Designed in the DRF. Thus, the design DRF is determined based on an initial occurrence value associated with a combination of at least one potential effect of failure and at least one potential cause of failure. The glide-path DRF is based on a completion of prevention and detection controls and recommended actions within a required target date of completion. The glide-path DRF enables the FMEA analyst to track the risk mitigation timeline during the product development cycle. In an embodiment, a history of the glide-path DRF is recorded in a pre-determined time range to track a progress of the risk mitigation for the FEMA project during the product development cycle. The capability DRF is based on a lowest occurrence value associated with a combination of at least one potential effect of failure and at least one potential cause of failure. The current DRF is based on an initial revised occurrence value on a successful execution of the prevention and detection controls associated with a combination of at least one potential effect of failure and at least one potential cause of failure.

The present disclosure (i.e., Graphic User Module 110, any part(s) or function(s) thereof) may be implemented using hardware, software or a combination thereof, and may be implemented in one or more computer systems or other processing systems. However, the manipulations performed by the present disclosure were often referred to in terms, such as comparing or checking, which are commonly associated with mental operations performed by a human operator. No such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein, which form a part of the system. Rather, the operations are machine operations. Useful machines for performing the operations in the system may include general-purpose digital computers or similar devices.

In an embodiment of the present disclosure, the present system is directed towards one or more computer systems capable of carrying out the functionality described herein.

The computer system 4800 includes at least one processor, such as a processor 4802. The processor 4802 is connected to a communication infrastructure 4804, for example, a communications bus, a cross over bar, a network, and the like. Various software embodiments are described in terms of this exemplary computer system 4800. After reading this description, it will become apparent to a person skilled in the relevant art(s) how to implement the system using other computer systems and/or architectures.

The computer system 4800 includes a display interface 4806 that forwards graphics, text, and other data from the communication infrastructure 4804 for display on a display unit 4808.

The computer system 4800 further includes a main memory 4810, such as random access memory (RAM), and may also include a secondary memory 4812. The secondary memory 4812 may further include, for example, a hard disk drive 4814 and/or a removable storage drive 4816, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. The removable storage drive 4816 reads from and/or writes to a removable storage unit 4818 in a well-known manner. The removable storage unit 4818 may represent a floppy disk, magnetic tape or an optical disk, and may be read by and written to by the removable storage drive 4816. As will be appreciated, the removable storage unit 4818 includes a computer usable storage medium having stored therein, computer software and/or data.

In accordance with various embodiments of the system, the secondary memory 4812 may include other similar devices for allowing computer programs or other instructions to be loaded into the computer system 4800. Such devices may include, for example, a removable storage unit 4820, and an interface 4822. Examples of such may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an erasable programmable read only memory (EPROM), or programmable read only memory (PROM)) and associated socket, and other removable storage units 4820 and interfaces 4822, which allow software and data to be transferred from the removable storage unit 4820 to the computer system 4800.

The computer system 4800 may further include a communication interface 4824. The communication interface 4824 allows software and data to be transferred between the computer system 4800 and external devices. Examples of the communication interface 4824 include, but may not be limited to a modem, a network interface (such as an Ethernet card), a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, and the like. Software and data transferred via the communication interface 4824 are in the form of a plurality of signals, hereinafter referred to as signals 4826, which may be electronic, electromagnetic, optical or other signals capable of being received by the communication interface 4824. The signals 4826 are provided to the communication interface 4824 via a communication path (e.g., channel) 4828. The communication path 4828 carries the signals 4826 and may be implemented using wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link and other communication channels.

In this document, the terms “computer program medium” and “computer usable medium” are used to generally refer to media such as the removable storage drive 4816, a hard disk installed in hard disk drive 4814, the signals 4826, and the like. These computer program products provide software to the computer system 4800. The disclosure is directed to such computer program products.

Computer programs (also referred to as computer control logic) are stored in the main memory 4810 and/or the secondary memory 4812. Computer programs may also be received via the communication interface 4804. Such computer programs, when executed, enable the computer system 4800 to perform the features of the present disclosure, as discussed herein. In particular, the computer programs, when executed, enable the processor 4802 to perform the features of the present disclosure. Accordingly, such computer programs represent controllers of the computer system 4800.

In accordance with an embodiment, where the system is implemented using a software, the software may be stored in a computer program product and loaded into the computer system 4800 using the removable storage drive 4816, the hard disk drive 4814 or the communication interface 4824. The control logic (software), when executed by the processor 4802, causes the processor 4802 to perform the functions of the system as described herein.

In another embodiment, the system may be implemented primarily in hardware using, for example, hardware components such as application specific integrated circuits (ASIC). Implementation of the hardware state machine so as to perform the functions described herein will be apparent to persons skilled in the relevant art(s). In yet another embodiment, the system is implemented using a combination of both the hardware and the software.

INDUSTRIAL APPLICABILITY

Generally, in FMEA project, various FMEA analysts are required to complete one or more tasks associated with sequential order of elements. Conventionally, the FMEA analysts use spreadsheets to fill the information and then the various spreadsheets are collated to track the progress of the FMEA project during a product development cycle. Also, the FMEA analysts need to perform various calculations such as value of RPN manually to find out the possible combination of causes and effects that needs risk mitigation.

In an embodiment, the user interface 112 provides a solution to the various FMEA analysts to track the progress of risk mitigation in the FMEA project during the product development cycle. As illustrated in FIG. 49, process 4900 details out the steps of facilitating the FMEA project. At step 4910, the GUI module 110 displays information pages on the user interface 112 to the various FMEA analysts, assigned to the particular FMEA project. The information pages may include placeholders for including information associated with the sequential order of elements. The information may include name of item or process, requirements associated with those items or process, potential failure modes, potential causes and effects associated with the failure modes, one or more controls and recommended actions associated with the various causes and failure mode combinations.

At step 4920, the GUI module 110 receives textual inputs from the FMEA analysts to be filled in the information pages. Conventionally, the FMEA analyst may only be able to provide the basic information regarding the sequential order of elements. In an embodiment, the user interface 112 enables the FMEA analyst to provide additional information associated with each of the sequential order of elements. Further, the user interface 112 also enables the FMEA analysts to upload attachments associated with the sequential order of elements and to link one or more other projects that may be related to the current FMEA project. The user interface 112 further enables the FMEA analyst to link NPI/CPI projects with the current FMEA project. Conventionally, the FMEA analysts use to manually calculate the RPN values based on the occurrence value, severity value and detection value. In an embodiment, the user interface 112 enables the FMEA analysts to view the RPN value associated with each possible combination of cause and failure mode. The user interface 112 automatically calculates an initial RPN and a current RPN once the required information such as initial and current values of occurrence, severity and detection is received from the FMEA analysts and thus, eliminating the risk of human errors.

At step 4930, the GUI module 110 represent the sequential order of elements in a tree structure format on the user interface 112. The user interface 112 includes the “FMEA Navigator” 710, which displays the sequential order of elements in the tree structure format. The first node in the tree structure includes the name of item or process step. Subsequently, the next node includes the one or more requirements/process step output associated with the item or process step. The next node includes one or more failure modes associated with the requirements or process step output. The subsequent node includes the one or more effects and causes associated with each of the failure modes. The subsequent mode includes the various controls or recommended actions associated with the cause and failure mode combination. The tree structure enables the FMEA analysts to view the association of sequential order of elements with each other. The tree structure also enables the FMEA analyst to navigate any element from the sequential order of elements by selecting the element to view the information associated with the element or double clicking the element to view an editable information page associated with the element.

In an embodiment, the GUI module 110 displays a real time status of the FMEA project in the user interface 112. The FMEA analysts may view the real time status of the FNEA project under the “Summary” tab in the user interface 112 and may also run a report to access pending executions of controls and recommended actions associated with the sequential order of elements. The status of the FMEA also includes visual indicators such as, but not limited to, flags, watch symbols, star symbol with either pending or overdue execution of controls or recommended actions. Further, the user interface 112 may provide a path on the status to view and/or edit the information associated with the sequential order of elements.

The user interface 112 may also enable the FMEA analyst to view one or more tasks assigned to the particular FMEA analyst on controls or recommended actions. In an embodiment, the FMEA analyst having a team leader or a project manager role may access the progress of the various tasks assigned to several other team members (FMEA analysts assigned to the project) in a particular FMEA project. In an embodiment, the FMEA analysts may also track the progress of the FMEA project through “DVP&R” tab which includes an execution status of various control and/or recommended actions associated with the sequential order of elements. In various embodiments, the FMEA analysts may export the status reports for the FMEA project in one or more formats such as XML spreadsheets. The FMEA analysts may import the XML spreadsheet into the user interface 112 and may update the status of the FMEA project in the user interface 112 based on the information included in the imported XML spreadsheets.

Further, at step 4940, the GUI module 110 develops risk charts to enable the FMEA analyst to visually track the risk mitigation progress in the FMEA project during the product development cycle. In an embodiment, GUI module 110 develops the risk chart for a single FMEA project or for a validation project that includes multiple FMEA projects. The GUI module 110 may develop two types of charts: Criticality Matrix Risk Chart (CMRC) and Proactive Reliability Risk Chart (PRRC).

In one embodiment, the CMRC may be used to visually present a criticality of potential failure modes and the risks associated with those failures. The CMRC is based on a correlation of severity values associated with potential effects of failure, and occurrence values associated with potential causes of failures. The CMRC is formed as a grid which is divided in three different zones: a risk mitigation zone 4210, a probable risk mitigation zone 4220 and a risk free zone 4230. The CMRC is divided in the three zones 4210, 4220, and 4230 based on the severity and occurrence values for each combination of cause and effect in the FMEA project or the validation project. Each cell with in the grid includes a total number of cause and effect combinations from the FMEA project corresponding to the occurrence and severity values plotted in the CMRC. In an embodiment, the three zones 4210, 4220, and 4230 in the grid may be populated based on industry standards, such as an AIAG standard.

In an embodiment, the risk mitigation zone 4210 includes all such combination of potential causes of failure and potential effects of failure that have a correlation of the severity value and the occurrence value greater than a predetermined threshold. Each of the cause and effect combinations in the risk mitigation zone may include one or more recommended actions from the FMEA analyst to mitigate the risk associate with those cause and effect combinations. The criticality of the risk associated with a cause/effect combination is based on the severity value and the occurrence value of the effect and the cause respectively. In an embodiment, the probable risk mitigation zone 4220 includes all such combination of potential causes of failures and potential effects of failure that have a correlation of the severity value and the occurrence value greater than a predetermined threshold. Each of the cause and effect combinations in the probable risk mitigation zone 4220 may include one or more controls such as prevention controls or detection controls. Further, in an embodiment, if any combination of potential causes of failure and potential effects of failure in the probable risk mitigation zone 4220 has an RPN value greater than a pre-determined value, then all those combinations have one or more recommended actions. The RPN is based on a correlation between the severity value, the occurrence value and the detection value. The detection value is associated with each combination of the potential causes of failure and the potential effects of failure. In an embodiment, the detection value is taken as a predetermined number to calculate the RPN if no inputs are provided by the FMEA analyst for the detection value. In an embodiment, the risk free zone 4230 includes all such combination potential causes of failure and potential effects of failure that have a correlation of the severity value and the occurrence value lesser than a predetermined threshold. Each of the cause and effect combinations in the risk free zone 4230 may not need any controls or recommended actions. In various embodiments, the three zones 4210, 4220 and 4230 may be visually separated from each other by color codes, a hatch pattern or the like. However, it will be apparent to a person skilled in the art that the three zones may be visually separated by using any other method known in the art.

In an embodiment, the FMEA analyst may track a progress of the risk mitigation in the FMEA project by comparing the initial CMRC and the current CMRC. The initial CMRC is based on an initial severity value and an initial occurrence value associated with a combination of at least one potential cause of failure and at least one potential effect of failure. In an embodiment, the initial CMRC may be revised based on an initial occurrence value associated with the combination of the at least one potential cause of failure and the at least one potential effect of failure. The initial occurrence value is revised based on an execution of at least one prevention control associated with the combination of the at least one potential cause of failure and the at least one potential effect of failure. Further, the current CMRC is based on a current severity value, and a current occurrence value associated with a combination of at least one potential cause of failure and at least one potential effect of failure. The current severity value and the current occurrence value is based on an execution of at least one recommended action associated with the combination of the at least one potential cause of failure and the at least one potential effect of failure. Further, the forecast CMRC is based on a forecast severity value, and a forecast occurrence value associated with a combination of at least one potential cause of failure and at least one potential effect of failure. The forecast severity value and the forecast occurrence value is based on a presumption execution of at least one recommended action associated with the combination of the at least one potential cause of failure and the at least one potential effect of failure.

In an embodiment of the disclosure, the PRRC is based on a timeline for risk mitigation during the FMEA project and a Dealer Repair Frequency (DRF). The DRF is a correlation of an occurrence value and an ability to predict that occurrence after the validation. The calculation of DRF is done for each failure mode and cause combination in the FMEA project. Specifically, the PRRC is based on the timeline for risk mitigation and a mean DRF. The mean DRF is a failure rate spread for a limited time-period in a product lifecycle.

While aspects of the present disclosure have been particularly shown and described with reference to the embodiments above, it will be understood by those skilled in the art that various additional embodiments may be contemplated by the modification of the disclosed machines, systems and methods without departing from the spirit and scope of what is disclosed. Such embodiments should be understood to fall within the scope of the present disclosure as determined based upon the claims and any equivalents thereof.

Claims

1. A computer-implemented method to facilitate a failure modes and effects analysis (FMEA) project associated with one or more components or process during a product development cycle, the method comprising:

displaying on the user interface one or more information pages associated with sequential order of elements to be completed by one or more FMEA analysts;

receiving with an aid of the user interface textual inputs from the one or more FMEA analysts for the one or more information pages associated with the sequential orders of elements; and

developing a risk chart for tracking a risk mitigation progress for the FMEA project associated with the one or more components or process during the product development cycle, based on the information associated with the sequential order of elements.

2. The computer implemented method of claim 1, wherein developing the risk chart includes developing a single risk chart for multiple FMEA projects.

3. The computer implemented method of claim 1, wherein the risk chart includes a criticality matrix risk chart (CMRC) and a pro-active reliability risk chart (PRRC).

4. The computer implemented method of claim 3, wherein the CMRC is based at least in part on a severity value associated with at least one potential effect of failure, and an occurrence value associated with at least one potential cause of failure.

5. The computer implemented method of claim 3, wherein the CMRC includes three zones based on the severity value and the occurrence value.

6. The computer implemented method of claim 5, wherein three zones includes:

a. a risk mitigation zone;

b. a probable risk mitigation zone; and

c. a risk free zone.

7. The computer implemented method of claim 6, wherein the risk mitigation zone includes at least one combination of potential causes of failure and potential effects of failure having a correlation of the severity value and the occurrence value greater than a predetermined threshold.

8. The computer implemented method of claim 7, wherein each of the at least one combination of the potential causes of failure and the potential effects of failure in the risk mitigation zone includes at least one recommended action.

9. The computer implemented method of claim 6, wherein the probable risk mitigation zone includes at least one combination potential causes of failure and potential effects of failure having a correlation of the severity value and the occurrence value greater than a predetermined threshold.

10. The computer implemented method of claim 9, wherein each of the at least one combination of the potential causes of failure and the potential effects of failure in the probable risk mitigation zone includes at least one of a prevention and detection controls.

11. The computer implemented method of claim 9, wherein each of the at least one combination of the potential causes of failure and the potential effects of failure in the probable risk mitigation includes at least one recommended action if an Risk Priority Number (RPN) for those combinations is greater than a pre-determined value.

12. The computer implemented method of claim 11, wherein the RPN is based on a correlation between the severity value, the occurrence value and a detection value.

13. The computer implemented method of claim 12, wherein the detection value is associated with each of the at least one combination of the potential causes of failure and the potential effects of failure.

14. The computer implemented method of claim 13, wherein the detection value is taken as a predetermined number to calculate the RPN if no inputs are provided for the detection value.

15. The computer implemented method of claim 6, wherein the risk free zone includes at least one combination potential causes of failure and potential effects of failure having a correlation of the severity value and the occurrence value lesser than a predetermined threshold.

16. The computer implemented method of claim 6, wherein the three zones are separated with at least one of a color code, a hatch pattern, and a heat map.

17. The computer implemented method of claim 2, wherein the CMRC includes an initial CMRC, a forecast CMRC and a current CMRC.

18. The computer implemented method of claim 17 further including comparing the initial CMRC and the current CMRC to track the risk mitigation progress for the FMEA project.

19. The computer implemented method of claim 17, wherein the initial CMRC is based on an initial severity value and an initial occurrence value associated with a combination of at least one potential cause of failure and at least one potential effect of failure.

20. The computer implemented method of claim 19 further including revising an initial CMRC based on a revised initial occurrence value associated with the combination of the at least one potential cause of failure and the at least one potential effect of failure.

21. The computer implemented method of claim 14, wherein the initial occurrence value is revised based on an execution of at least one prevention control associated with the combination of the at least one potential cause of failure and the at least one potential effect of failure.

22. The computer implemented method of claim 17, wherein the current CMRC is based on a current severity value, and a current occurrence value associated with a combination of at least one potential cause of failure and at least one potential effect of failure.

23. The computer implemented method of claim 22, wherein the current severity value and the current occurrence value is based on an execution of at least one recommended action associated with the combination of the at least one potential cause of failure and the at least one potential effect of failure.

24. The computer implemented method of claim 17, wherein the forecast CMRC is based on a forecast severity value, and a forecast occurrence value associated with a combination of at least one potential cause of failure and at least one potential effect of failure.

25. The computer implemented method of claim 24, wherein the forecast severity value and the forecast occurrence value is based on an presumption execution of at least one recommended action associated with the combination of the at least one potential cause of failure and the at least one potential effect of failure.

26. The computer implemented method of claim 3, wherein the CMRC on the user interface provides a path to view a status report including information associated with the sequential order of elements.

27. The computer implemented method of claim 26, wherein the information in the status report includes:

a. one or more of an item, or process step;

b. requirement associated with item or process step output;

c. at least one potential failure mode associated with the item or process;

d. an initial severity value, an initial occurrence value and an initial detection value associated with a combination of at least one potential effect failure and at least one potential cause of failure associated with the potential mode of failure;

e. one or more prevention or detection controls associated with the combination of the at least one potential effect failure and the at least one potential cause of failure;

f. a validation identification of the FMEA project;

g. one or more recommended action associated with the combination of the at least one potential effect failure and the at least one potential cause of failure;

h. a forecasted severity value, a forecasted occurrence value and a forecasted detection value associated with the combination of the at least one potential effect failure and the at least one potential cause of failure;

i. a current severity value, a current occurrence value and a current detection value associated with the combination of the at least one potential effect failure and the at least one potential cause of failure;

j. the one or more FMEA analysts assigned for an execution of the one or more prevention or detection controls and the one or more recommended actions; and

k. a start date, target completion state associated with the one or more prevention or detection controls and the one or more recommended actions.

28. The computer implemented method of claim 27, wherein the sequential order of elements includes one or more visual descriptors associated with the elements of the sequential order of elements.

29. The computer implemented method of claim 28, wherein the one or more visual descriptors provides a status or issues associated with the elements.

30. The computer implemented method of claim 27, wherein the status report provides a path to view and edit information associated with the elements of the sequential order of elements.

31. The computer implemented method of claim 26, wherein the status report provides a path on to export the status report in MS Excel.

32. The computer implemented method of claim 3, wherein the PRRC is based on a timeline for risk mitigation during the FMEA project and a Dealer Repair Frequency (DRF).

33. The computer implemented method of claim 32, wherein the PRRC includes a mean DRF, a design DRF, a glide-path DRF, a capability DRF, a target DRF, a current DRF, and a history DRF.

34. The computer implemented method of claim 33, wherein a mean DRF is a failure rate spread for a limited time-period in a product lifecycle.

35. The computer implemented method of claim 33, wherein the design DRF is determined based on an initial occurrence value associated with a combination of at least one potential effect of failure and at least one potential cause of failure.

36. The computer implemented method of claim 33, wherein the glide-path DRF is based on a completion of prevention and detection controls and recommended actions within a required target date of completion.

37. The computer implemented method of claim 36, wherein a history of the glide-path DRF is recorded in a pre-determined time range to track a progress of the risk mitigation for the FEMA project during the product development cycle.

38. The computer implemented method of claim 33, wherein the capability DRF is based on a lowest occurrence value associated with a combination of at least one potential effect of failure and at least one potential cause of failure.

39. The computer implemented method of claim 33, wherein the target DRF is based on a specified target timeline provided by the one or more FMEA analysts for the risk mitigation.

40. The computer implemented method of claim 39, wherein the target DRF is provided by the one or more FMEA analysts on the user interface.

41. The computer implemented method of claim 33, wherein the current DRF is based on an initial revised occurrence value on a successful execution of the prevention and detection controls associated with a combination of at least one potential effect of failure and at least one potential cause of failure.

42. A system comprising:

a processor for facilitating a failure modes and effects analysis (FMEA) project associated with one or more components or process during a product development cycle,

a tangible, non-transitory memory configured to communicate with the processor, the tangible, non-transitory memory having instructions stored thereon that, in response to execution by the processor, cause the processor to perform operations comprising: displaying on the user interface one or more information pages associated with sequential order of elements to be completed by one or more FMEA analysts; receiving with an aid of the user interface textual inputs from the one or more FMEA analysts for the one or more information pages associated with the sequential orders of elements; and developing a risk chart for tracking a risk mitigation progress for the FMEA project associated with the one or more components or process during the product development cycle, based on the information associated with the sequential order of elements.

43. An article of manufacture including a non-transitory, tangible computer readable medium having instructions stored thereon that, in response to execution by a computer-based system for facilitating a failure modes and effects analysis (FMEA) project associated with one or more components or process during a product development cycle, cause the computer-based system to perform operations comprising:

displaying on the user interface one or more information pages associated with sequential order of elements to be completed by one or more FMEA analysts;

receiving with an aid of the user interface textual inputs from the one or more FMEA analysts for the one or more information pages associated with the sequential orders of elements; and

developing a risk chart for tracking a risk mitigation progress for the FMEA project associated with the one or more components or process during the product development cycle, based on the information associated with the sequential order of elements.