Question 2 of 7: Computer-Aided Process Planning — Justification, Types and Selection

Question 2: Computer-Aided Process Planning — Justification, Types and Selection (20 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.

Part (a) — why process planning is computerised. Process planning is the bridge between a released design and the shop floor: it converts a drawing or solid model into an ordered list of operations, machines, tools, fixtures, speeds, feeds and standard times. Done manually it is slow, expensive and, above all, inconsistent, and those three weaknesses are the justification for automating it.

The first reason is consistency. Two experienced planners handed the same part will routinely produce two different routings, because each draws on a personal store of remembered jobs. Different routings mean different cycle times, different tooling and different costs for the same geometry, which makes estimating unreliable and standard costing meaningless. A computer-aided system applies one encoded logic to every part, so the plan for a given feature set is reproducible.

The second is the retirement problem. Process-planning skill is accumulated over decades and lives in the heads of a handful of senior people. Encoding that experience — as a family of standard plans, or as decision logic — converts a personal asset into a corporate one that survives the planner's departure and can be taught to a junior in weeks rather than years.

The third is speed and cost. In a job shop the planning effort per order is nearly independent of order size, so on small lots the planning cost is a large fraction of the total. Retrieving and editing an existing plan takes minutes where writing one takes hours, which shortens quotation lead time and lets the shop bid on work it would otherwise decline. Faster planning also shortens the design-to-production interval, which is the metric customers actually feel.

The fourth is integration. A computer-generated plan is a structured data object, not a piece of paper. It can feed the MRP system with routings and run times, the cost system with standard hours, the scheduling system with work centre loads, the NC programming system with tool lists, and the shop-floor control system with operation sequences. Manual planning breaks that chain at every hand-off and forces the same information to be re-keyed, with the transcription errors that always follow.

Finally there is optimisation. A computer can evaluate alternative machine assignments, tool selections and cutting parameters against a cost or time objective in seconds, and can enforce company standards — preferred tooling, approved suppliers, allowed tolerance grades — that a hurried planner may overlook. The result is fewer distinct tools in inventory, better machine utilisation and fewer plans that turn out to be infeasible when the job reaches the floor.

Part (b) — variant and generative CAPP compared. The two families share their purpose, their inputs and much of their supporting infrastructure, and differ in how the plan itself is produced.

How they are alike. Both accept a part description and emit a route sheet with operations, machines, tooling and times. Both depend on a classification scheme — a group-technology code or a feature description — to characterise the part. Both require a maintained database of machines, tools, materials and standard times, and both are only as good as that database. Both aim at the same benefits set out in part (a), and both output into the same downstream systems.

How they differ. A variant system is a retrieval system. Parts are grouped into families by GT code; each family has a standard plan stored against it; the system finds the family that matches the new part's code, retrieves the standard plan and presents it to a planner, who edits the differences. It is essentially a very disciplined filing cabinet. Its logic is simple, it can be implemented on modest hardware in months, and it works well where parts genuinely fall into families. Its limits are equally clear: it can only produce plans that resemble plans it already holds, a truly novel part falls outside every family, the standard plans must be created and maintained by hand, and a human planner is still needed for the editing step. It also tends to perpetuate whatever inefficiency was baked into the original standard plan.

A generative system synthesises the plan from first principles. It reads the part's features, tolerances, surface finishes and material from the CAD model or a feature description, and applies encoded decision logic — decision trees, decision tables, expert-system rules, sometimes optimisation routines — to select processes, sequence them, choose machines and tools, and compute cutting parameters and times. No stored plan is retrieved; each plan is built. The advantages are that a genuinely new part can be planned, that human intervention approaches zero, and that the logic can be tuned to optimise rather than merely to imitate. The costs are the mirror image: the decision logic is very expensive to develop and validate, it must cover every process the shop owns, it depends on a rich and clean feature description that many CAD models do not supply, and maintaining it as machines and tooling change is a permanent engineering commitment. In practice most commercial "generative" systems are semi-generative hybrids — generative logic for the operation sequence, retrieved standards for the details.

Part (c) — recommendation for the small job shop. For a small job shop running a few NC machines alongside several manual machines, a variant (retrieval-based) CAPP system, supported by a simple group-technology coding scheme, is the appropriate choice. The reasoning is economic and organisational rather than technical.

A job shop's work repeats in kind even when it does not repeat in detail: shafts, brackets, flanges, plates and housings recur constantly in slightly different sizes. That is exactly the condition under which family-based retrieval performs well, and a shop of this size will have a manageable number of families — perhaps fifteen to thirty. The capital and skill required are small: a coding scheme, a set of standard plans written by the shop's most experienced planner, and a database that can live on a desktop system. It can be implemented incrementally, one family at a time, so it begins paying back before it is finished. Because a planner still reviews and edits every plan, the mixed machine population is handled naturally — the planner assigns the operation to the NC machine or to a manual machine according to lot size and complexity, a judgement that is difficult and expensive to encode. A generative system, by contrast, would demand an investment in decision logic out of all proportion to the shop's volume, and would need a feature-rich CAD model that a job shop receiving customer drawings often does not have.

Two supporting recommendations follow. First, the shop should couple the CAPP system to its NC programming so that a retrieved plan pulls up the associated part programs for the family — that is where the largest single time saving lies. Second, it should adopt the GT coding discipline even before buying software, because the classification itself immediately exposes duplicate tooling, candidates for cell formation, and quoting patterns, and it is the prerequisite for any later move to a semi-generative system.