How can manufacturers document performance targets for PLC and HMI integration?

When two suppliers are asked to quote the same PLC and HMI integration, one answers with a hardware list and a delivery date, and the other comes back a week later with a list of performance targets, each carrying a number, a test condition, and a name against it. Both look professional on the day the requirement is issued. The difference shows up at commissioning, and later, when a line has to be moved, copied, or defended in front of an auditor. Documenting performance targets for the control layer decides whether acceptance is measurable or arguable, and for manufacturers buying automation that layer belongs to whoever operates the line, not only to the integrator.

We build process equipment and automation systems on one site in Shenzhen, so the same document has to serve a cleaning-equipment skid, a lamination cell and a battery line. Across those jobs the pattern repeats: the machine is specified in detail and the control layer that runs it is specified in adjectives. Below is the form we ask buyers to write control targets in before the work starts, so both sides are signing the same thing.

Why undocumented control targets become schedule risk

A PLC program and an HMI screen pass the first walk-through easily. They start, they stop, the buttons do what they say. What fails later is rarely visible that day: a cycle that holds for twenty parts and drifts on the twenty-first, an alarm that clears itself so nobody investigates the cause, a recipe an operator edits at two in the morning with no trace of it, a machine that cannot be restarted after a power cut without the supplier's engineer.

Each of those is a target nobody wrote down. While a performance target stays in an email thread, three things happen. Acceptance has no boundary, so the project closes when the supplier says it is finished rather than when the line proves it. Support has no baseline, so a fault reported eight months later is described in impressions. Training has no reference, so the knowledge lives with whoever commissioned the line, and leaves with them. Undocumented targets are not a paperwork gap; they are why control-layer disputes cost more time than the equipment they sit on.

One form for every target: metric, threshold, condition, method, owner

Most documentation attempts fail because they record the number alone. A takt figure on its own cannot be tested, because it does not say which part, at what speed, with what downtime allowance, measured by whom, over what window. A target a manufacturer can sign has five fields, and a control specification is simply that table filled in for the controls instead of the mechanics.

• Metric – what is measured, named so two engineers read it the same way.
• Threshold – the value that separates acceptable from not, with units.
• Condition – the part, material, speed, utility state and shift pattern under which the number was obtained, and what has been excluded.
• Method – where the measurement comes from: the counter or instrument that produced it, the sample size, and who may call a failure.
• Owner – the named person on each side who signs the result, not the company.

The condition and method fields carry most of the value. A performance figure published for any machine is bound to the test conditions behind it, and the same applies to a control program. A throughput number taken on a dry cycle is not a throughput number, and an alignment figure taken on the supplier's own sample is not a figure for your part. Write the target, then write the condition it was obtained under. On a supplier's own sample, or on a dry cycle with no material, or on your part at your speed with your utilities: these produce three different numbers, and only one of them is worth signing.

Performance targets for the PLC layer

Cycle and state timing

Fix what the cycle time includes before anyone quotes it. The measured state matters: an automatic cycle that includes load and unload waiting is not the same number as an automatic cycle only. Write the takt, then write the states around it separately, because a line that holds takt and then takes minutes to resynchronise after an interruption does not hold takt.

• Target takt, plus the idle and interlock time allowed inside it.
• Time to the first good part from cold start, from a controlled stop, and from an emergency stop.
• Recovery time for each alarm class listed in the specification, stated as the seconds the machine may be down.
• Which stations may run in parallel, and what the program must do when one is taken out for maintenance.

Process value control and recipe integrity

Every process value the PLC manipulates needs its own row: the target, the band around it, and what the program does when the value leaves the band. This is where integration specifications are thinnest, because the mechanical specification carries tolerance language and the control specification carries none. Temperature, pressure, force, vacuum, position and flow each need a stated band and a stated response, and the response must say whether the machine continues, holds, alarms or stops.

Then define the recipe rules, because the recipe is where a commissioned line changes quietly. How many recipes may be stored. Which fields an operator may edit and which are locked to an engineer level. What returns after a power loss, and whether the recipe that comes back is guaranteed to be the one that ran. Who is told when a value is edited. Where a line produces parts that carry a specification to a downstream customer, recipe control is a quality requirement before it is a controls preference.

Interlocks, alarms and machine state

Ask for the alarm list as a deliverable, not a buzzer behaviour. It should name each alarm, its trigger, what stops, what is required to clear it, and whether clearing it is allowed to hide the fact that it happened. An alarm that clears itself is the most commonly undocumented item on a production line, and the reason a scrap batch is found hours after it started.

Interlocks deserve their own table: guard doors, light curtains, vacuum presence, part-in-position, pressure relief, and any safety function that must hold in a maintenance mode. State what a bypass may do, who may enable it, and require that every bypass leaves a record. Where equipment works with heat or pressure, this documentation is also a facility matter, since the safety boundary has to match what the building and the crew can actually support.

Performance targets for the HMI and the person using it

HMI targets are documented least, because a screen looks finished as soon as it exists. They are testable like any other requirement, and the test is behavioural rather than electrical.

• Language and terminology – screen, labels and alarm text in the language of the crew running the machine, using the words already in your method sheets rather than the integrator's internal naming.
• Access levels – operator, maintenance and engineer levels, with a record of which level changed what, and an explicit statement of whether a supplier service level exists and what it may modify.
• Indication speed – how quickly the screen reflects a state change, and what it shows while a slow action is running.
• Troubleshooting support – whether an alarm names the cause and the check to perform, or only the symptom; this is the difference between a shift recovering a line and a shift telephoning a supplier.
• Readability at the machine – viewing distance, gloves, ambient light, and whether the panel can be reached without opening a guard.

A practical test to write into the acceptance document: hand a trained operator three of the alarms this line is expected to produce, and require recovery without a telephone call. That single line tests screen wording, alarm structure, access levels and training at once, and it is far cheaper than the alternative discovered during a launch week.

Data and traceability targets

If the line must produce records, the fields have to be agreed before the program is written, because they determine what the PLC has to hold and where the timestamps come from. Decide what is recorded per unit, per batch or per shift; who writes it; how long it is kept; and in what form it leaves the machine. A statement that a controller is ready for a manufacturing execution system is not a specification, and it cannot be tested at acceptance.

• The fields themselves: process values, alarm events, recipe in use, operator identity, part identifier.
• Direction of each field, which side writes and which side reads.
• The bus or protocol exposed at the boundary, and who else may use it.
• Whether the machine records without a network present, and what it does with data while disconnected.

How acceptance tests turn targets into evidence

Write acceptance in three stages and let each one release the next payment. A factory test on your own product and your own instrument, witnessed by your engineer. An installation test that checks utilities, interlocks and safety functions on the machine you actually receive. A production run at the agreed takt, with the defect definitions you signed and an agreed duration.

For the control layer specifically, the acceptance document should include items nobody tests by default: what the machine does when a process value is forced out of band, whether the alarm list matches what the screen displays, whether the recipe set survives a power cut, whether a bypass leaves a record, and whether two shifts produce the same output from the same recipe. Keep the pass values at the end of the process rather than at the machine datasheet, because that is the number production is measured on.

A documentation set that outlives commissioning

Ask for the control package as a list of deliverables in the purchase document, the same way mechanical drawings are listed. At minimum: a functional description of each machine state; the tag list and interlock table; the alarm list with causes; the recipe structure and access levels; the electrical and pneumatic diagrams with revision numbers; the program and HMI backup, plus instructions for taking the next one yourself; and the training record naming who was trained on which modules and at which access level.

Verify the backup once, in front of the engineer who made it, before they leave. A backup that has never been restored has unknown value. This is also the moment to fix the support path: a named technical contact, response times by fault severity, and what your own engineers may do without voiding anything.

When standard controls are not the right answer

A standard control system carries boundaries someone has already solved: known modes, published utility requirements, protection functions, and a parameter set with limited editable fields. It is usually the cheaper route. Custom control development earns its cost in four situations: your line has to run to a takt you define rather than one published in a catalogue; the site's utilities cannot supply what a standard configuration expects; the process must produce records an auditor or a customer will read; or safety functions have to interlock with an existing line rather than stand alone.

In those cases ask the supplier to answer by subsystem rather than by brand. Which parts of the control are carried over from a production model, which are written for your process, who tests the result and against which acceptance criteria. A supplier that builds its own equipment, runs hardware testing in-house, and provides engineering services and non-standard automation equipment can carry specification, build and test under one signature. Where it can only write a specification, choose a different arrangement rather than hoping the gap closes at commissioning.

Getting this started without adding months

Ask any controls supplier for their standard acceptance checklist before the requirement is frozen. Suppliers that have delivered lines already hold such a list, and they will usually improve it when a buyer asks for specific items in it. Then write your own targets in the five-field form, keep the pass values at the end of the process, and put the deliverable list into the purchase document as numbered attachments with a payment step behind each complete set.

Three questions test whether the documentation you already have would survive contact with production. Could a second-shift technician recover the three most likely alarms using only the delivered documents? Could a maintenance planner order every wearing part without telephoning anyone? Could a new process engineer state what the machine was proven to do, and on which samples? If any answer is no, the missing document should be requested while the supplier's engineer is still standing at the machine, which is the cheapest moment it will ever be available.

Send us your line layout, your takt requirement, the records your customer expects, and the utilities actually available at the station, and we will return the target list and deliverable set we would sign against for that installation.