22-Mec-B5 Product Design and Development · May 2017

Question 2 of 7: Design as process and as outcome (15 marks)

Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)

Notes on this paper

Paper format. National Exams, May 2017 — 16-Mec-B5 Product Design and Development. Three hours, OPEN BOOK, one of two calculators (Casio or Sharp). Question 1 is compulsory and carries 40 marks; four of the six remaining questions are chosen at 15 marks each, for 100 marks. The paper states that most answers are expected in essay form or as tables, figures and charts, and that clarity and organisation are marked. All seven questions are solved here.

Reference texts (22-Mec-B5).

Ulrich, K. T. and Eppinger, S. D., Product Design and Development, 6th ed., McGraw-Hill — the framework text for this subject (Ch. 2 development processes, Ch. 5 identifying customer needs, Ch. 6 product specifications, Ch. 7–8 concept generation and selection, Ch. 11 design for manufacturing, Ch. 16 patents and intellectual property).
Dieter, G. E. and Schmidt, L. C., Engineering Design, 5th ed., McGraw-Hill (Ch. 3 problem definition, Ch. 8 embodiment design, Ch. 11 materials selection, Ch. 13 risk and reliability).
Pahl, G., Beitz, W., Feldhusen, J. and Grote, K.-H., Engineering Design: A Systematic Approach, 3rd ed., Springer (systematic conceptual and embodiment design).
Boothroyd, G., Dewhurst, P. and Knight, W. A., Product Design for Manufacture and Assembly, 3rd ed., CRC Press (DFA index, part-count minimisation).
Ashby, M. F., Materials Selection in Mechanical Design, 5th ed., Butterworth-Heinemann (material indices, the translate–screen–rank–document method).
Kalpakjian, S. and Schmid, S. R., Manufacturing Engineering and Technology, 8th ed., Pearson (process selection and process economics).
Canadian frame: CSA/ANSI B651-18 Accessible design for the built environment (operating-force ceilings), CAN/CSA-C22.2 appliance safety, the Patent Act (R.S.C. 1985, c. P-4) as administered by CIPO, and CCOHS noise-exposure guidance (3 dB exchange rate, 85 dBA criterion).

Check — engineering assumptions declared once for the whole paper. The exam gives no product data, so every number below is a stated design assumption chosen to be representative of the product class, not a measurement: blender motor 1200 W input at 62 % electromechanical efficiency; 85 % of shaft power dissipated in the charge as viscous work; interlock collar breakaway torque 2.6 N·m; door-lock Weibull shape 2.3 and characteristic life 180 000 cycles; injection-mould tooling CAD 85 000. Each assumption is flagged where it is used, and every conclusion is stated as a consequence of it. A real design would replace each with a measurement or a supplier quotation before release.

Question 2 — Design as process and as outcome (15 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Given. A qualitative question on design methodology, to which one quantitative illustration is attached: an iteration in which each pass removes a fixed fraction of the residual gap between the current design and its target specifications, with a per-pass gap-reduction factor $\rho = 0.55$ and an acceptance threshold of 5 % residual gap.

Find. Functional definitions of design-as-process and design-as-outcome, the important steps of the process, the role and the cost of iteration (including the number of passes the assumed convergence requires), and the requirements that make a design complete.

Approach. Define the two senses of the word by what each one is for, lay out the process as the standard systematic sequence, then argue iteration both qualitatively (it is how uncertainty is retired) and quantitatively (convergence rate against escalating cost of change), and close with the four-part completeness test.

A. Design as a process and design as an outcome

Design as a process is the purposeful, iterative transformation of an incompletely stated need into a fully specified, buildable and verifiable description of an artefact, carried out under constraints of cost, time, safety, law and available technology. Functionally, it is a decision-making activity: its inputs are a need, a set of constraints and a body of technical knowledge; its mechanism is the repeated generation of candidate solutions and their elimination against criteria; and its output is information, not hardware. The definition matters because it identifies what a designer is accountable for — the quality of the decisions and of the evidence behind them — rather than for the elegance of the result.

Design as an outcome is the complete information set that defines the artefact unambiguously enough that it can be made, verified, used, maintained and disposed of by people who were not present when it was designed. Functionally, it is a specification: the geometry and tolerances, the materials and their specified conditions, the processes and their parameters, the assembly relationships, the test and acceptance criteria, the service and end-of-life instructions, and the record of the decisions and assumptions behind them. The everyday phrase “a good design” usually refers to this second sense, but the second sense is only ever as good as the first: a well-executed process is what makes an outcome defensible, and a good outcome reached without process is not repeatable.

B. Important steps in a design process

Figure 2.1 — The systematic design process, with the two iteration returns that matter most: validation back into specification, and concept selection back into need definition when the concepts reveal that the need was framed wrongly.

The steps below follow the systematic tradition of Pahl and Beitz and the development-process framing of Ulrich and Eppinger; the names differ between texts but the functions do not.

1. Identify the need and define the problem. Establish what is actually wanted and by whom, distinguish the symptom from the need, and set the boundary of the system being designed. This step ends with a written problem statement and a business case, and time spent here is recovered several times over.

2. Establish customer requirements and gather information. Structured need elicitation, benchmarking of existing solutions, a patent and standards search, and a review of the governing regulations. The output is a ranked, weighted needs list.

3. Write target specifications. Convert each need into a metric with units, a test method and marginal and ideal values, as in Question 1(D). This is the contract between the customer's language and the engineer's.

4. Conceptual design. Decompose the overall function into sub-functions, generate solution principles for each (internally and by external search), combine them into whole-product concepts, and select among them by screening and scoring. This is the step with the greatest leverage over final cost and performance and the lowest expenditure to date.

5. Embodiment design. Give the selected concept a preliminary form: layout, architecture, module boundaries, materials and processes, and the first round of engineering analysis and sizing. Failure modes are identified here (FMEA) and designed against.

6. Detail design. Complete geometry, tolerances, materials specifications, standard-part selection, drawings and models, the bill of materials, and the manufacturing and assembly documentation.

7. Prototype, test and validate. Build representative hardware and test it against the specifications of step 3 — performance, life, safety, regulatory compliance and user trials. Validation asks whether the right product was built; verification asks whether the product was built right. Both are required.

8. Production release, launch and support. Process qualification, pilot production, ramp-up, then field monitoring, warranty analysis and the feedback of both into the next programme and into the current one through engineering change.

C. The importance of iteration

Iteration is not a symptom of poor planning; it is the mechanism by which a design programme converts assumptions into knowledge. At the start of a programme the largest uncertainties are not in the analysis but in the problem statement itself, and no amount of care in a single forward pass can remove them, because the information needed to correct the assumptions is generated only by testing the design that the assumptions produced. Each iteration retires a portion of that uncertainty.

The rate matters, and it can be modelled. If each design–build–test pass removes a fixed fraction of the remaining gap between the current design and its target specifications, the residual gap after $k$ passes is $g_k = \rho^{k}$ with $\rho = 0.55$ for the assumed programme. Requiring the residual gap to fall to 5 %,

$$\rho^{k} \le 0.05 \;\Rightarrow\; k \ge \frac{\ln 0.05}{\ln 0.55} = \frac{-2.996}{-0.598} = 5.01 \;\Rightarrow\; \boxed{k = 6 \text{ iterations}}$$

with the gap falling 100 % → 55 % → 30.3 % → 16.6 % → 9.2 % → 5.0 % → 2.8 %. Two consequences follow immediately. First, the schedule must contain the iterations rather than pretend they will not occur; a plan with one prototype build is a plan that will meet approximately half its specifications. Second, since the number of passes is set by $\ln(\text{target})/\ln\rho$, the way to shorten a programme is to raise $\rho$ — to learn more per pass, through better instrumented tests, designed experiments rather than one-factor-at-a-time changes, and simulation that pre-screens the variants — not to cut the number of passes.

Against this stands the escalating cost of change. The widely used order-of-magnitude rule is that a change costing roughly CAD 1 000 at the concept stage costs about CAD 10 000 in embodiment, CAD 100 000 once tooling is cut, CAD 1 000 000 in production and CAD 10 000 000 as a field recall — four orders of magnitude across the programme. The reconciliation of the two arguments is the central discipline of design management: iterate hard and often early, where a pass is cheap and $\rho$ is high because the design space is still open, and reduce iteration to controlled verification once the architecture is frozen. Iteration late in a programme is failure; iteration early is the work itself.

D. Key requirements that define a final complete design

A design is complete when it satisfies all four of the following, and a shortfall in any one of them means the design is not finished regardless of how good the other three are.

1. Function — it demonstrably does what was asked. Every target specification has been verified by test or by accepted analysis, with the evidence recorded; the design meets its performance, life, reliability and safety requirements over the full range of specified operating and misuse conditions.

2. Form — the geometry is completely and unambiguously defined. Complete models and drawings, a full tolerance scheme with the datums and the stack-up analysis behind it, ergonomics and interfaces resolved, and the aesthetic and brand intent settled rather than left to the tool maker.

3. Material and process — every part is made of something specified, by a route that exists. Each material identified by grade, specification and condition, not by family; each process selected, capable at the required tolerance and volume, and sourced from a qualified supplier; the cost verified against the target at the planned volume.

4. Compliance, documentation and life-cycle provision. The applicable standards and regulations identified and met with certification evidence (in Canada, the CSA and ULC certification route, the relevant CAN/CSA-C22.2 appliance standards, and any provincial requirement); the intellectual-property position cleared by a freedom-to-operate search; and the documentation that lets the product live — assembly and test instructions, user and service manuals, spares list, and end-of-life instructions. A design that performs perfectly but cannot be certified, cannot be sold without infringing, or cannot be serviced is not a complete design.

The four are coupled, not independent, and that coupling is why the process in part B iterates: a change of material changes the achievable form and the available processes, a change of process changes the achievable tolerance and therefore the function, and a compliance requirement discovered late can invalidate all three.

Table 2.1 — Question 2 results summary
Item	Result
Design as process	Decision-making activity turning a need into verified information
Design as outcome	The complete, unambiguous specification of the artefact and its life cycle
Process steps	Need → requirements → specifications → concept → embodiment → detail → validation → release
Gap reduction per iteration (assumed)	$\rho = 0.55$
Iterations to reach a 5 % residual gap	$k = 5.01 \rightarrow 6$ passes
Cost-of-change escalation, concept to field	~10× per stage, four orders of magnitude
Completeness test	Function, form, material and process, compliance and documentation

Topic. Design methodology: the dual sense of the word “design”, the systematic process, convergence through iteration, and the definition of design completion.

Key relations. Geometric convergence of the specification gap, $g_k = \rho^{k}$, so $k = \ln(g_{\text{target}})/\ln\rho$; the order-of-magnitude cost-of-change escalation across development stages; the function–form–material–process completeness set.

Why this works. Modelling iteration as geometric decay of a residual gap captures the essential behaviour of real development: progress is proportional to what remains wrong, so the tail is long and the schedule must budget for it. Because the required number of passes depends on the logarithm of the target, tightening the acceptance threshold from 5 % to 1 % costs only about three more passes, whereas halving the learning rate per pass nearly doubles the whole programme — which is why investment in better test instrumentation and in simulation pays more than schedule pressure does. Pairing this with the escalating cost of change gives the standard conclusion in a defensible form: front-load the iteration.

Common pitfall. Treating iteration as rework to be eliminated, which produces a plan with a single prototype and a programme that discovers its problems in production; and declaring a design complete on function alone, when the incomplete item is usually the tolerance scheme, the supplier qualification or the certification evidence.

Source. Pahl & Beitz, Engineering Design: A Systematic Approach, 3rd ed., Ch. 4–7; Ulrich & Eppinger, 6th ed., Ch. 2 (Development Processes and Organizations); Dieter & Schmidt, Engineering Design, 5th ed., Ch. 1–2 and Ch. 8.

← Question 1 Next: Question 3 →