1. Start with the process, not the panel
Before naming a PLC brand or an HMI size, write down what the machine has to do. A control specification that begins with hardware tends to lock in one vendor and hide genuine requirements. A specification that begins with the process can be evaluated against several designs.
State the sequence of operations as the operator will experience it: load, index, process, verify, unload, reject path. For each step, record the input condition that permits it to start, the interlock that forbids it, and the output it produces. If a step is manual, say so and describe the guarding that applies. Writing this out early is where most ambiguity disappears.
2. Specify the machine states and the transitions between them
Every control system moves through a small set of states: power-off, reset, manual/jog, setup, automatic, paused, faulted, and cleaning or maintenance mode. Document each state explicitly, and document who may change state and under what conditions.
The transition table matters more than the state names. What happens to a partly completed cycle when an operator presses pause? Does the fault log clear automatically or does it require a deliberate acknowledgement? What does the machine do on a power interruption mid-cycle? These are the questions that surface in acceptance testing if nobody asked them in writing first.
3. Treat safety requirements as a separate, numbered section
Safety functions should never be buried in general feature text. List each safeguard, the sensor or device that implements it, and the required response. Emergency stop coverage, guard interlocks, light curtains, pressure-sensitive edges, and mechanical restraints each need their own line.
For each item, record which standard the supplier is expected to design to, and which market the machine will be shipped into. If the buyer has already completed a hazard and risk assessment, attach it and reference individual items from it in the specification. A supplier asked to design safety features without the risk assessment will design to their own assumptions, which is exactly where disputes begin.
4. Document the electrical envelope in the buyer's units
Ambiguity about power is a frequent cause of installation delay. Specify supply voltage and frequency, single- or three-phase, available service capacity, compressed-air pressure and flow if used, and the footprint available for the control cabinet. Where a machine runs on a fixed shop supply, note the socket type and circuit protection the buyer provides, and where the supplier's responsibility ends.
Mobile and battery-powered equipment needs its own requirements: charge method, runtime per shift, protection against electrical faults, and behaviour when the energy source is depleted mid-task. A mobile steam cleaning machine used inside an indoor garage, for example, has duty-cycle and ventilation constraints that a fixed machine plumbed into a shop supply simply does not, and those differences belong in the requirement text rather than being discovered on site.
5. Write measurable acceptance criteria
Every functional requirement needs a test attached to it, or it is not a requirement. Phrase criteria the way an inspector will verify them: cycle time measured over a stated number of consecutive cycles, dimensional results measured with a named gauge, availability tracked over a defined trial period, fault recovery demonstrated on a specified failure mode.
Separate factory acceptance from site acceptance, and state which criteria apply at each stage. Record what the buyer must provide for the site test — material, utilities, operators, shift pattern — and what happens if the machine fails a criterion. Agreeing on remedy before purchase removes most of the emotion from a failed test.
Where performance depends on the process chemistry as well as the machine, specify the outcome rather than the machine settings. A buyer specifying steam degreasing equipment for a machining line will get better bids by stating the residue that must remain absent after cleaning, the parts or surfaces involved, and the required throughput, than by dictating nozzle pressure alone.
6. Fix the interfaces and the data expectations early
If the equipment must talk to a SCADA system, a MES, a barcode scanner, or another machine, name the protocol, the data points, and who owns the integration test. A vague line reading "PLC must be networked" invites an incompatible solution.
Decide what the machine must record: cycle counts, fault history, recipe changes, operator sign-off. Specify retention, export format, and whether the data has to survive a power loss. Teams that postpone this decision usually end up paying to add logging after the code is frozen.
7. Name the deliverables and the revision process
Require the drawing set explicitly: electrical schematics, terminal and bill-of-material schedules, panel layout, pneumatic diagrams, the PLC and HMI source or documented export, spare-parts list with part numbers, and an operator manual in the language the crew actually reads. State the format and whether native files are included.
Then document how changes to the specification are handled. A change-control clause that records who approved a change, when, and what it did to price and schedule protects both parties. Without it, the requirements document quietly diverges from the built machine, and the divergence is discovered at handover.
8. Where the buyer's team lacks controls depth
Many purchasing teams know their process intimately and their controls less so. That gap is manageable if the specification stays process-led and the supplier is brought in during drafting rather than at quotation stage. Requiring a written design review and an approved design package before fabrication starts converts unknown requirements into a documented, agreed scope.
For buyers who need engineering input on the equipment itself, customized cleaning equipment work at PowerDe typically begins with the buyer's process description, since the company builds non-standard automation and application-specific machines rather than catalogue units alone. Bringing that kind of engineering conversation into the specification phase is usually cheaper than correcting a specification after the machine exists.
A practical order of work
Draft the process sequence and machine states first. Add numbered safety requirements with the applicable standards. Add the electrical and utility envelope. Add acceptance criteria for every functional line. Add interfaces and data. Close with deliverables and change control. Review the document with the operators who will run the machine before it goes out for quotation — they find the missing step that no engineer thought of, and finding it on paper is the cheapest place it can be found.
