This chapter is from the book
This chapter is from the book
This chapter is from the book
Flow-Down or Decomposition
If the initial design capability analysis does not provide high confidence that the critical parameter will reside comfortably and consistently within the specification window, robust against noises ranging from manufacturing variation through variations in use conditions, environments, system interactions and measurement error, then the team will need to engage in robust design and optimization efforts that will generally be performed at the subsystem, module, subassembly and/or component levels. Consequently, the next steps involve identifying the parameters at these levels that are affecting the performance of the critical parameter at the system level. This is referred to as the critical parameter flow-down process.
A valuable tool for critical parameter management in general, and for this critical parameter flow-down and the later process for critical parameter flow-up (Chapter 14) is called Cognition Cockpit (http://www.cognition.us). This software tools provides an easy-to-use, Web-based interface that handles virtually all aspects of critical parameter management and provides interfaces to other software commonly used in DFSS and in product development.
The critical parameter flow-down is a team activity involving the appropriate expertise to identify x's, n's, and subordinate y's that affect the performance of the system level critical parameter. The second House of Quality can help with this flow-down. The approach used previously in the system-level or first House of Quality, described in Chapter 7, would be used again at the subsystem level or the next level down in the product hierarchy, but with the measurable system-level parameters along the left side and subordinate measurable technical parameters for the subsystem described across the top, as in Figure 10.5. Although this approach tends to provide a useful set of subordinate y's for each subsystem, the control factors (x's) and noises (n's) are a bit more difficult to obtain from this method.
The term "x's" refers to factors that are under the design engineers' control: design choices, component choices, or settings of continuous variables, like the choice of a resistor or capacitor value or for a voltage-controlled oscillator or the setting on a voltage supply.
The term "n's" refers to noises: factors that will not be under the design engineers' control when the product is operating out in the field among customers. Noises like environmental temperature might be controllable in the lab environment, which will be useful for evaluation purposes, but cannot be controlled once it leaves the controlled environment—a customer may use the product during a summer in Phoenix, Arizona, or Riyadh, Saudi Arabia, and the same or a different customer may use the product during winter in Alaska or Sweden.
The term "subordinate y's" refers to measurable parameters at a lower level in the flow-down that affect the system-level performance for the critical parameter and are in turn affected by other factors and parameters at an even lower level in the flow-down. A mechanical example of this might be the water resistance of the system being flowed down to subordinate y's representing the water resistance of various inserts, holes, and user interfaces that cannot be affected directly but can be affected indirectly through the choices of O-rings and dimensions that can ensure acceptable water resistances for those subordinate y's. An electronic example might be the total isotropic sensitivity, corresponding to the weakest signal strength that the system can dependably handle, which can be flowed down to subordinate y's representing the antenna gain and the LNA (low noise amplifier) gain at the component level, which cannot be directly affected but can in turn be affected by decisions about the design of the antenna and selection of the LNA part or components in the LNA.
The flow-down effort can be facilitated by the use of the P-diagram (Figure 10.3) discussed earlier in this chapter, which could already have identified the noises and may simply require differentiation between the subordinate y's and the x's. Alternatively, the team can use a second House of Quality approach or participate in a meeting to brainstorm the factors that affect the critical parameter and subsequently differentiate the factors as noises, x's, or subordinate y's, with an additional step to further explore the subordinate y's to complete the flow-down to x's and n's.
The process described here has proven very efficient at quickly generating a more thorough first-pass flow-down, which can subsequently be refined and expanded or "fleshed out." It also can be used to quickly generate P-diagrams and subsystem or component Houses of Quality or entered into the Cognition Cockpit database.
Procedure for Critical Parameter Flow-Down or Decomposition
- Ask the critical parameter owner to describe the critical parameter, how it's measured, current estimates about its most likely value and possible distribution, and any progress that's already been made towards developing confidence that the critical parameter will be capable.
- Discuss with the team: Is the critical parameter clearly measurable as-is? How would it be measured? If the measurement approach is clearly defined, would meeting that measurable requirement fulfill customer and business expectations? If not, develop an operational definition, a measurable definition for the critical parameter.
- Brainstorm subrequirements with the team, first pass. The template shown in Figure 10.13, available for download at http://www.sigmaexperts.com/dfss/, can help with this process.
Figure 10.13 Template for critical parameter flow-down process and for associated P-Diagrams; this template can be downloaded at
- Classify the subrequirements into subordinate y's, x's, and noises. Subordinate y's are measurable, but not directly controllable (i.e., there is not a "knob" to change the value of the subordinate y to a selected value). Control factors or x's are directly controllable and affect the value of the critical parameter or a subordinate y to the critical parameter. Noises or n's are factors that affect the critical parameter or a subordinate y, but that the team does not control in normal usage (although the team might be able to control a noise like temperature in a lab).
Classify the subordinate y's into continuous requirements, ordinal requirements, and binary discrete or obligatory requirements (pass/fail or meets/doesn't meet requirements).
Continuous requirements have a full range of possible values—like a voltage measurement; ordinal requirements have integer values, where higher or lower is better—like a score of 1 to 7 on a Likert survey form, or the number of drops to failure, or the number of clicks to get to a certain screen.
Binary requirements are either acceptable or unacceptable—like whether an Excel-compatible table of data is output from the software or not.
For each subordinate y, ask the team—is each subrequirement necessary?
If this set of subrequirements was satisfactorily met, would that provide sufficient confidence that the product will meet expectations for the critical parameter? If not, brainstorm what additional subordinate y's are needed to have sufficient confidence that the customers will be satisfied that this critical parameter has been fulfilled.
- For each necessary subordinate y that is continuous or ordinal, the team should discuss their confidence. If the team is highly confident that a subordinate y will be satisfactorily achieved, then it need not be flowed down further, but otherwise the team would brainstorm other lower level subordinate y's, control factor (x's) and noises (n's) that affect that subordinate y. Continue until the lowest level of the flow-down consists of only x's, n's, and subordinate y's that the team is highly confident will be satisfactorily achieved.
- For each necessary subordinate that is binary or obligatory, ask the team: What are the goals? Should we consider a Pr (success) metric (as discussed in Chapter 14)? Would fault tree analysis be helpful for this obligatory requirement? (Fault tree analysis is discussed in Chapter 9.)
- Put the results of the flow-down of the critical parameter into a diagram, with the critical parameter or Y placed at the top or left side of the diagram, and the subordinate y's, x's, and n's linked by lines or arrows. If appropriate, capture this flow-down in a database such as the critical parameter management database associated with Cognition Cockpit. If appropriate, capture part or all of the flow-down as a P-diagram.
- Ask the team or assign team members to obtain goals/preliminary spec limit(s) for the continuous and ordinal requirements.
)
){kind=link}
){kind=link}