Home Random Page



Embodiment Checklist

To supplement the general embodiment process (Figure 12.6), a second basic method is the application of an embodiment checklist (after Pahl and Beitz). Such a checklist, as illustrated in Table 12.1, provides a systematic approach to apply proven design principles during product development. This checklist is created from generic (and historically proven) design principles of ensuring robustness, clarity, simplicity, and safety in a product.

Robustness is the design principle that seeks to minimize the variability in performance of a product under all expected environmental and user conditions. This principle provides a basis for understanding the impact of noise on a product's performance.

Clarity is the basic principle that all functions should be unambiguously specified, in form, parameters, manufacturing, and assembly. Unintended functions should not be present in a product. It also assumes that product functions (or function chains) will be implemented as independent as possible. In doing so, the performance of each product function (or function chains) can be controlled and modified without deteriorating or compromising the performance of other product functions.

The design principle of simplicity, on the other hand, is the minimization of information content within a product design.


Example: Drive Train Subsystem of a Radio-Controlled (RC) Car


Consider a product found in hobby stores: a RC car. Electric RC cars are entertainment products that emulate full-scale on-road or off-road vehicles. They are controlled by a transmitter (speed and steering) and are powered by 6-7 D-cell batteries. An embodied version of a popular RC car is pictured in Figure 12.7.

Applying the checklist to the RC car, one of the questions (Layout,

Geometry, and Materials category) is stated as, "Does the chosen layout ensure freedom from resonance?" Many components are subject to resonance, including all of the rotating components (bearings, shafts, etc.) and the helical suspension springs. Of these components, the drive shafts of the car are the most susceptible due to their nominal long length and small cross section.


Figure 12.8 illustrates a possible drive shaft layout. One issue with drive shafts is whether the shaft will excessively vibrate and thereby cause premature failure or annoying dynamics. One mode of the vibration is when the shaft is not centered as it rotates-when the middle of the shaft is radially offset outward as the shaft rotates. Based on a downward deflection of the shaft due to its weight, the critical speed of shaft may be calculated by


where Wcr is the critical speed for resonance (in rpm), g is the acceleration constant due to gravity, and 8 is the lateral deflection of the shaft (Juvinall and Marshe). Substituting variables from Figure 12.8, the critical speed for the current shaft layout is approximately 3600 rpm. On the other hand, based on the choices of motor and gear train variables, the maximum driven speed of the shaft will be 2500 rpm. Based on this analysis, the shaft will not resonate. If the shaft speed were close to or greater than the critical speed, the shaft dimensions would have to be modified (radius increased slightly) to satisfy the resonance checklist item.

As shown by this example, embodiment checklists such as the one illustrated in Table 12.1 motivate the careful consideration of both performance issues and possible failure modes of a product. Checklists of this type are constructed from historical data and past product developments. They should be used, in conjunction with the general embodiment process, to carefully create detailed subassembly layouts and properly select parameters that will ensure a robust design.



In addition to the general embodiment process (Figure 12.6) and embodiment checklist (Table 12.1), systems modeling techniques can be applied when embodying a concept. Systems models are representations of a product that predict the product's performance under varying input (environmental or boundary) conditions.

Systems Modeling

Functional models, as discussed in Chapter 5, represent high-level systems models of a product. Inputs of materials, energy, and signals are simultaneously converted to desired outputs. During the concept development phase of a product, these models provide a basis for systematically generating product architectures (Chapter 9) and solution concepts.

High-level model: After identifying the physical principles and assumptions for each customer need, a balance relationship is created to document a high-level physical model. Control volume methods or cause-and-effect diagrams may be used to document the balance relationship, where the "effect" is the customer need, and the "causes" are the physical principles. The ultimate goal is to refine the "causes" to the level of physical variables.

Balance relationships: The last task in formulating mathematical models for a product is to convert the balance relationships into a set of mathematical equations. Basic engineering principles may be used to choose the appropriate scaling law relationships (Miller). Variable ranges from the product's layout drawings or bill of materials should be used to augment the mathematical relationships with appropriate parameter values. If such variable values are unavailable, appropriate ranges are chosen.

Physical prototype models: In some cases, cycle-time, economic, or product-complexity considerations may prevent the development of a mathematical model. The creation of a physical prototype can be used as an alternative modeling approach. Prototype models should be designed in such circumstances. The intent here is to create a bench-top or other experiment (not an entire product prototype) for a customer need, focusing on the effected product components and variables. For instance, a customer need may exist for an electric wok lid handle to "fit comfortably in the user's hand during operation." A mathematical model of this need is not directly apparent; however, physical prototypes that vary shape, size, and texture of the handle may be designed for analysis and testing.


Date: 2016-03-03; view: 1010

<== previous page | next page ==>
II. OVERVIEW AND CONTEXT | Alignment of Forces
doclecture.net - lectures - 2014-2019 year. Copyright infringement or personal data (0.002 sec.)