Step 1: Scope Definition and Project Planning
Step 1 covers the scope definition, project team make-up and project planning aspects of the study.
Scope
Define what is included as well as what is excluded from the scope of the FMEA. A clear definition of the scope minimizes the probability of “scope creep.”
- For a DFMEA, define aspects of the (product) design and its components and subassemblies that are to be included in the study and those that are to be excluded.
- For a PFMEA, the scope defines the boundaries of the process to be studied, indicating whether the “entire” process including support utilizes should be studied or only the “base” process (without support processes) should be studied.
- For a FMEA-MSR (Supplemental FMEA for Monitoring and System Response), the scope should define which sensors, control units and actuators with their corresponding hardware and software should be studied for safety relevance, safety goals (according to ISO 26262) and (legislative) regulatory requirements.
The management team is responsible for setting the scope of the study. If the team finds it necessary to go beyond the original scope, that expansion should be confirmed with, and approved by, the management team.
Project Plan
The following “Five T’s” from the draft standard should be covered in the FMEA kickoff meeting. |
|
Team | Who needs to be on the team?
The make-up, roles and responsibilities of the team are covered in this section.
Project teams conducting FMEAs are comprised of a Core Team plus an Extended Team of subject matter experts called upon when needed.
- The Core Team should include a group of people with multi-disciplinary, cross-functional backgrounds and experiences. Core Team roles include an overall (FMEA) Project Manager, Technical Lead and Facilitator. The make-up of the Core Team for DFMEAs, PFMEAs and FMEA-MSRs will involve members with different disciplines and backgrounds representing applicable subject matter experience and expertise.
- An Extended Team of subject matter experts should be available to support the Core Team on an as-needed basis.
|
|
|
Timing | When is this due?
Using FMEAs early in the development process can mitigate risks that may be more difficult and costly to address later. Conducting an FMEA in each of the 5 sequential phases of the APQP process is recommended.
- APQP Phase 1: Plan and Define the Program
- APQP Phase 2: Product Design & Development Verification
- APQP Phase 3: Process Design & Development Verification
- APQP Phase 4: Product & Process Validation
- APQP Phase 5: Feedback, Assessment & Corrective Action
|
|
|
inTent | Why are we here?
Every FMEA Team member should have had training in the intent, purpose and methodology of the 6-Step FMEA Process. Participating in an FMEA study requires a commitment in both time and effort; team members must be aware of the time requirements and be willing and able to meet that obligation. |
|
|
Tools | How do we conduct the analysis?
Commercial software packages, use of a Structure Tree or a Spreadsheet are all acceptable methods of documenting the results of the FMEA study. |
|
|
Tasks | What work needs to be done?
A primary task of the FMEA Team is to complete the 6-Step Process, resulting in the following deliverables:
- Identify and evaluate potential risks of failure.
- Analyze the causes and subsequent effects of failures (if a failure does occur).
- Describe and characterize existing preventive and detection controls.
- Recommend actions to mitigate or reduce risks.
Upon completion and documentation of the FMEA study, the team will review their outcomes and recommendations with management (and customers if appropriate). Which action plans and who will be tasked with implementing them will be determined with guidance from management.
- Items not requiring action should be marked as “No revision planned” to indicate that the risk assessment was completed.
- Items requiring action will be marked as Open, Decision Pending, Implementation Pending. Discarded or Completed to indicate the status of the actions.
|
|
|
FREE DOWNLOAD | FMEA Preparedness Checklist
We recommend that a standard checklist be used at the beginning of any FMEA to make sure the organization has planned adequately for the study. We have a new PDF version of our FMEA Preparedness Checklist for the 2018 AIAG-VDA FMEA. It will help you identify and gather the information needed to effectively and efficiently begin the FMEA study. |
|
Structure Analysis is used to identify and breakdown the system (design or process) into the system, subsystems and component elements so that a comprehensive risk assessment can be conducted.
Regardless of the type of FMEA (design, process or MSR), tools such as block diagrams and structure trees are used to create a visualization of the design or process. This helps the team stay focused on the task at hand without ignoring downstream and upstream impacts the item or process step has on performance.
The Structure Analysis is the basis for Step 3: Function Analysis |
|
Because of the unique differences between Design, Process and FMEA-MSRs, we will handle each type separately as it is done in the draft handbook. Depending on your job responsibilities, you may not need to know how all three work, so feel free to skip ahead to the information relevant to your work. |
|
A DFMEA Structure Analysis uses the boundaries set by the Scope Definition (Step 1) to identify the overall (design) system, subsystem(s), assemblies and/or components to be studied for a (System or Component) DFMEA.
- It is important that the DFMEA Team understand the chain of customers to effectively identify the various functions, requirements and specification of the design elements so that potential effects of failure modes can be correctly categorized. Customers include:
- The chain of (internal or external) manufacturing or assembly operations using the design
- The eventual End User
- A Block (or Boundary) Diagram or a Structure Tree (or Tree Diagram) is useful to provide a visual representation of the design. Editorial note: We suggest a detailed blueprint can also be used.
- A Block Diagram delivers a visual depiction of the entire system or design, showing the boundaries of the FMEA (i.e. what is and is not included) and noting every interface between the system elements.
- A Structure Tree shows the hierarchy of a structure (system) in a graphical form.
- Editorial note: A spreadsheet can be used to represent the system structure. A detailed blueprint or drawing of the design (system, subsystem or component) noting all interfaces can provide another valuable perspective for the team.
- All interfaces, interactions and other relationships between system elements must be noted including:
- Physical connections, energy transfers, supporting or conditioning features and data exchanges should all be noted.
- It is vital to study interfaces because they can often account for a significant portion of failure modes. Don’t forget to investigate the interfaces between subsystems, assemblies and components in addition to those that are part of the system elements themselves.
|
|
A PFMEA Structure Analyses uses the boundaries set by the Scope Definition (Step 1) to identify and breakdown the process flow into Process Items, Process Steps and Work Elements.
- A Process Flow Diagram or a Structure Tree (or Tree Diagram) provide a visual representation of the process. Editorial note: A detailed “traveler” (work instructions) may also be used to document the process flow.
- A Process Flow Diagram depicts all the process operations that are required to produce the manufactured or assembled product that fall within the scope of the PFMEA study.
- Editorial note: We find it useful to use a Top-Down Process Flowcharting approach where each major step of the Top-Down Flowchart represents a Process Item. Transactional (i.e. office or service) processes can also be effectively analyzed with Top-Down Process Flowcharts.
- Process Flow Diagrams, Structure Trees and Travelers can be used as the input for a spreadsheet representing the system structure.
|
|
The structure of an FMEA-MSR (FMEA for Monitoring and System Response) is typically comprised of both hardware and software elements . The FMEA-MSR is a new addition to the types of FMEAs making its debut in the 2018 AIAG-VDA FMEA Handbook. Here is a concise article describing exactly what an FMEA-MSR is.
- Two methods are generally used to visualize a MSR System Structure:
- Block (or Boundary) Diagrams defne the scope of the design typically from a sensor to a control unit to the source of engagement (i.e. a motor).
- A Structure Tree can be at the fully assembled level (i.e. a vehicle) or it can be at an interface (i.e. limiting the analysis to a subsystem or component).
- Editorial note: A spreadsheet can be used to represent the system structure.
- Many FMEA-MSR analyses involve “mechatronics,” a multidisciplinary field that combines traditional mechanical and electronics systems with computer, telecommunications, and control technologies as applicable.
|
|
|
|
|
|
|
|
|