Special Purpose Machine Requirements: How to Turn a Manual Process into an Engineering Brief

An operator loads a part, adjusts it slightly, checks something, presses a button, and removes the result. From a distance, the process looks straightforward. Up close, the operator is making several decisions that the proposed machine has not been told about. Special purpose machine requirements begin by uncovering that work before you replace it with a mechanism.

This article is about discovering and defining the automation task. It comes before the purchasing brief in the machine RFQ guide. An RFQ helps suppliers price a scope; process observation helps you discover what that scope should contain. The distinction matters because a beautifully formatted specification can still describe the wrong process with exceptional confidence.

1. Observe the process as it actually happens

Watch more than a demonstration arranged for the engineering visit. Observe normal production, replenishment, changeover, and recovery from an interruption. Ask permission before recording people or customer material. Capture the sequence, the information used, and the conditions that change the work. A short explanation from the operator can reveal why a part is rotated, why a surface is wiped, or why one batch is handled differently.

Separate observation from interpretation. "The operator taps the part twice before loading" is an observation. "The part needs an automatic tapper" is a proposed solution. Ask what the action accomplishes and whether the underlying condition can be removed. The eventual machine might need a positioning feature, a preparation step, a different incoming specification, or no equivalent action at all.

Include the people who perform and maintain the operation, not only the person sponsoring automation. Their knowledge should become reviewable requirements and examples. It should not remain a verbal promise that someone will explain the difficult cases after the equipment arrives.

2. Break the operation into actions and decisions

Create a process map with material entering, actions occurring, observations being made, decisions changing the route, and acceptable output leaving. Distinguish physical work from information. An operator may visually confirm orientation before clamping; the future machine needs an equivalent verified condition or a design that makes the wrong orientation impractical. Simply replacing the hands does not replace the judgment.

Give the steps identifiers so later timing and fault discussions refer to the same operation. If the process has branches, show them rather than compressing everything into one ideal sequence. This map becomes an input to machine state design, but do not jump to implementation before agreeing on the intended behavior.

3. Define the material envelope and acceptable output

Collect representative material across the intended range: dimensions, mass, stiffness, surface conditions, packaging, and known defects. Record how samples relate to future supply. A sample from one convenient batch does not establish the range. Ask which variation the incoming process can control and which variation the machine must tolerate. Those are commercial and operational decisions as well as mechanical inputs.

Define acceptable output in terms that can be checked. "No damage" needs an agreed inspection method and examples of unacceptable marks or deformation. "Correctly assembled" may require position, force, orientation, or another product-specific criterion. Use the actual product requirements and responsible specialists where measurement or assessment is needed. Do not let the automation team invent quality limits because nobody else has written them down.

• Identify minimum, nominal, and maximum material conditions where relevant.
• Keep examples of normal variation and known unacceptable input.
• State how material is presented and who controls that condition.
• Define output quality and how acceptance is judged.
• Record what the machine should reject, pause for, or send for manual review.

4. Measure a baseline without designing from the fastest cycle

Record times with their context: material type, operator task, sequence, pauses, and whether the output was acceptable. Separate productive work from waiting, refilling, inspection, changeover, and rework. The quickest observed cycle can demonstrate possibility without describing sustained operation. The slowest cycle can reveal an exception without representing every unit. Keep the distribution and its causes visible.

For an illustrative station, suppose a typical observed sequence includes loading for 4 seconds, positioning for 2 seconds, processing for 6 seconds, and unloading for 3 seconds. The serial total is 15 seconds. That does not prove the automated target should be 15 seconds or faster. First determine which steps may overlap, which observations are missing, and what the process must deliver over the intended operating period.

Use the cycle-time calculation guide for the next level of analysis. A timing model is more useful when it explains the sequence and assumptions than when it offers an impressive rate with no loading or quality allowance.

5. Choose what to automate and what to leave outside

A special purpose machine does not have to automate the whole operation at once. Evaluate whether manual loading, automatic processing, and assisted inspection are an appropriate first boundary. Consider material presentation, upstream variability, downstream capacity, maintenance capability, and the business need. A fully automatic feed system can be justified, but it should solve a defined problem rather than satisfy an aesthetic preference for nobody being in the photograph.

Map every retained handoff. Who loads, confirms, refills, removes rejects, or changes the product variant? Define the information and physical interface at each boundary. If an operator remains responsible for a decision, give them clear feedback and appropriate access. If the machine owns it, define the detection and handling requirements. Ambiguous shared responsibility tends to appear later as an unexplained stoppage.

Compare a standard machine, a modified standard platform, and custom development before committing to a new architecture. The standard-versus-custom machine guide helps determine whether your requirement actually demands special equipment.

6. Include exceptions, recovery, and service in the brief

Walk through missing material, double loading, incorrect orientation, a failed observation, interrupted power, and a process that does not complete. Define the required outcome for each: reject, controlled pause, operator intervention, or another reviewed response. The appropriate safety behavior needs assessment by the responsible specialists. Do not define recovery only as "try again" when an earlier action may already have changed the product.

Ask what evidence the machine should preserve. Unit identity, cycle stage, fault, relevant measurements, and operator intervention can make investigation possible. Also describe cleaning, adjustment, replenishment, and expected service tasks. Maintainable machine design explains why these requirements belong before the layout is frozen.

7. Turn observations into a requirement and verification register

Write requirements that describe the needed result, conditions, and verification approach. Keep the rationale and source nearby. For example, if the process must handle two package sizes, identify both ranges and how a test will cover them. If changeover time matters, define when timing starts and ends and what tools or preparation are included. Avoid mixing several unrelated conditions into one sentence that nobody can decisively pass or fail.

NASA product-verification guidance describes verification methods including test, analysis, inspection, and demonstration. Use the distinction to choose appropriate evidence rather than insisting every requirement needs the same physical test. Your register can be concise while still making the link between the requirement and its check explicit.

Observation or business need:
Process step and material condition:
Required outcome and allowed variation:
Requirement identifier and owner:
Assumptions and unresolved questions:
Proposed verification method:
Test configuration or review evidence:
Acceptance decision and change history:

8. Test the risky assumption before detailing the full machine

Choose the uncertainty with the largest effect on feasibility. It might be handling a flexible package, detecting a subtle defect, achieving a repeatable insertion, or separating tangled parts. Scope a focused experiment with representative samples and a pass criterion. You may not need a finished machine to decide whether the proposed process is viable.

Record the experiment setup and limits. A successful bench trial may establish one mechanism principle while leaving durability, operating variation, assembly, and integration unresolved. If it fails, examine whether the requirement, incoming material, or concept should change. The custom machine development workflow places these investigations in the larger engineering sequence.

Keep the resulting concept alternatives and trade-offs. A lower-cost manual assist may meet the business objective more convincingly than a fully automated system with an unstable input process. Engineering should be allowed to recommend that outcome without being judged for producing fewer moving parts.

9. Review the brief with the people who must use the result

Bring the process map, representative samples, timing observations, quality criteria, exception model, and remaining questions into one review. Include production, maintenance, quality, and the person who approves the business scope. Resolve disagreements about what the machine must prove before they turn into conflicting acceptance expectations. Then issue the engineering brief with its revision and open-item register.

SolveMpire can discuss the transition from manual work to a machine concept through our engineering services. Start with the operation, the variation, and the decisions people currently make. That creates a more useful conversation than asking for a robot to replace a process nobody has described yet.