- Position within DFSS Flow
- Flow-Down for Hardware and Software Systems
- Anticipation of Potential Problems: P-Diagrams and DFMEA
- Target and Spec Limits
- Measurement System Analysis
- Capability Analysis
- Flow-Down or Decomposition
- Flow-Down Examples
- Initial Tolerance Allocation
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Anticipation of Potential Problems: P-Diagrams and DFMEA
System requirement flow-down also involves anticipation of potential problems. At the system level, a P-diagram and FMEA can be part of the concept generation and selection process for the system, as described in Chapter 8, and the system-level FMEA is included in the flowchart for identification of critical parameters, as described in Chapter 9.
As the flow-down proceeds iteratively, similar anticipation of potential problems should be subsequently applied for each critical parameter, or at the subsystem/subassembly level and the component level—and possibly at the manufacturing process level. Some perspectives should underline the importance of this anticipation as the flow-down proceeds: the system level flow-down will naturally involve a bird's-eye view of failure modes, and will involve a broader cross section of expertise for this purpose—but anticipation of failure modes and mechanisms at subsystem and module/component levels will involve a more focused set of experts to dissect the potential problems involved at that deeper, more detailed level. Essentially, at these subsequent iterations, the subsystem and component under consideration becomes "the system" for the team. It is worth noting that many of the subsystems for complex electronic products could literally be the "system" or product in other situations. For example, many cellular phones include digital cameras—but digital cameras are separate products or systems for camera manufacturers. Many cell phones ("music phones") incorporate music players, which also exist as separate products. In turn, many music players as products include flash drives, and some companies sell flash drives as products.
Either as an integrated subsystem, or as a separate product, anticipation of potential problems is a vital step toward prevention of problems. The P-diagram (Figure 10.8) and DFMEA (Figure 10.9) can be useful for the module and component-level concept generation and selection process described in Chapter 8, and also valuable in anticipating and preventing problems with aspects that were not selected as critical parameters (or flowed-down from critical parameters) but that could impact the success of the product if not adequately addressed.
)
Figure 10.8 Tool summary for P-diagram
)
Figure 10.9 Tool summary for design failure modes and effects analysis (DFMEA)
A P-diagram (Figure 10.8) offers several benefits. It can help with the development of the DFMEA, in which the error states or deviations from the ideal function (at the lower right of P-diagrams) could suggest failure modes to be included in the DFMEA, and the noises (at the top of the P-diagrams) could suggest potential causes for the failure modes.
As will be seen later in this chapter, the team approach for identifying control and noise factors used in developing the P-diagram can be leveraged in flowing down requirements to the next level. The control factors portion of the P-diagram generally are the x's in the flow-down, and the noises in the P-diagram obviously are the noises in the flow-down. The missing pieces are the subordinate y's—subrequirements that can be flowed down to other subordinate y's, x's, and n's. If the critical parameter does not involve subordinate y's, then the P-diagram can be used for the flow-down. However, many critical parameters cannot be directly flowed down to the final control factors with one P-diagram, and the P-diagram just provides a good start.
The P-diagram can also prove useful in generation and subsequent evaluation of alternative concepts for the subsystem, module, or component, particularly in terms of considering the noises that can affect performance when brainstorming potentially robust design approaches—the relative insensitivity of the alternative concepts to those noises can and should be considered in selecting a superior concept for the subsystem, module, or component.
The P-diagram can also prove valuable during transfer function determination (Chapter 13), in terms of initializing the identification of control and noise factors to use in an experimental design approach. The P-diagram will also prove valuable during optimization (Chapter 14), for evaluating and optimizing robustness against the noises. Some of the noises from the P-diagram can also be used as stress factors or for verification of reliability (Chapter 17).
FMEA (including system FMEA and design FMEA or DFMEA) has been discussed in Chapter 9, but it will be briefly reviewed here. The objective of DFMEA (summarized in Figure 10.9) is to consider the ways a product, subsystem, function, or interaction can fail, then analyze the risks, and take action where warranted. Typical applications include preventing defects, improving processes, identifying potential safety issues, and increasing customer satisfaction. It can be applied throughout the development life cycle. To be more effective, the DFMEA should relate to the nature of the development process itself. In either case, it considers overall architecture and functionality problems while at the same time addressing process problems. Therefore, DFMEA is an effective engineering tool for evaluating systems at a number of stages in the design process.
DFMEA evaluates risks posed by potential failure modes by considering the severity of the impact if the failure mode occurred, the probability that the failure mode could occur (based upon the probabilities for occurrences of potential causes of the failure mode), and the possibility that the problem would be detected in time. These three aspects of the risk are rated on a scale of 1 to 10, and then multiplied to provide RPN indices (on a scale of 1 to 1000) that can be treated as numerical assessments of risk. DFMEA and associated assessments are performed in a team setting, the atmosphere for which can become rather intense. It has been suggested that the DFMEA process be broken into two to three shorter sessions, during which the team is locked in a meeting room, and necessities (drink, raw meat . . .) are tossed over the wall.
There are systems that are heavily software oriented and that could benefit from a software DFMEA effort. The objective of a software DFMEA is to identify all failure modes in a software artifact. Its purpose is to identify all catastrophic and critical failure probabilities so they can be minimized as early as possible. For example, a common problem in software involves memory leaks. A memory leak is an unintentional memory consumption by a computer program where the program fails to release memory when no longer needed. Memory is allocated to a program, and that program subsequently loses the ability to access it due to program logic flaws. A memory leak can diminish the performance of the computer by reducing the amount of available memory. Eventually, too much of the available memory may become allocated and all or part of the system or device stops working correctly, the application fails, or the system slows down unacceptably. For example, code that has a "malloc" (a subroutine for dynamic memory allocation) or a "new function constructor," which is evaluated each time it is encountered, can increase the risk of creating a memory leak. Memory leaks can corrupt and misalign pointers (which reference values stored elsewhere in memory), and may cause part or all of the system to go down; the system may have difficulty recovering, and in severe cases, key data may be lost.
DFMEA and P-diagrams can be used and reused through many of the subsequent steps of DFSS. This continuing value is realized because DFMEA and P-diagrams, in concert, help the team conceptualize and share an understanding of the risks by assessing the risks in terms of the severity or impact, the probability of occurrence, and the opportunities for errors. The team can also gain insight into noises as potential sources of variation, stresses, and failures.