What the two halves do in a machine
The programmable logic controller carries the machine logic: the sequence of steps, the interlocks that stop a motion until a condition is met, the outputs to valves, drives and heaters, and the reading of sensors and safety devices. The human machine interface carries the operator's side: the current machine state, the alarms and why they fired, the parameters an operator is permitted to change, and the recipe or job selection. Under customized steam cleaning equipment, electrical control capability is listed as PLC control, HMI human machine interface, motion control, sensor integration, electrical cabinet design and safety control system, which is a useful way to see the split, because each of those items has to be designed before the code is written rather than chosen afterwards.
Integration means the two are designed against one list of variables. A fault that the controller detects but never names on the panel becomes a machine that is stopped with no explanation; a screen that shows a value the controller is not actually using becomes a number people argue about during a shift handover. When the variable list is shared from the start, the alarm text, the parameter limits and the recorded values all come from the same source. Whether a machine has to run unattended for part of a shift, with nobody standing at the panel when something goes wrong, raises the same requirement harder.
When integration is the right answer
Integration earns its place when people touch the machine during production and the machine has states worth seeing. On the PowerDe manufacturing automation page, the cases named for needing automation are low labour efficiency, unstable quality, repetitive process actions, detection that relies on manual judgement, capacity that has to increase, and existing lines that need retrofitting. Every one of those has a control side: the change is not only a new mechanism but a new set of states an operator and a supervisor have to read and trust. A single automated station added to a manual process, an added detection station on an old line, or a retrofit that adds safety control and data recording to existing equipment all sit in this category. The same page lists PLC and HMI control among the deliverables for automated chemical stations and lists the PLC and HMI programme among the engineering outputs of a manufacturing automation project, which is the practical signal that the panel is treated as a delivered item and not an accessory.
The reverse case is equally worth naming. A machine with one fixed cycle, no changeover, no recipe, no data requirement, and one trained operator who never touches parameters does not need a designed panel. A separate control layer in that situation is cost, a spare part, and a training item with no benefit.
What integration is not
A screen mounted on the guard is not integration. Integration shows up in decisions you can check on the machine: who can change a parameter and within what range; what happens to an in-progress cycle when a guard opens; whether an alarm names the sensor and the condition or only a code; whether the machine can be restarted after a stop without clearing evidence of the stop; whether a recipe change takes effect on the next part or mid-cycle; and whether the values an operator sees are the values the controller acted on. If those questions have no answer in the enquiry, the panel is decoration.
Machine vision inspection, motion control and safety control systems are also named on the same capability list, and they interact with the panel directly. A vision station that rejects parts has to report the reason somewhere an operator can act on it. A safety function that stops a motion has to be distinguishable on screen from an ordinary stop, otherwise the first thing a shift does is try to reset it.
Where whole-line automation sits in this decision
A buyer asking for an Industry 4.0 demonstration factory is asking for integration at its most demanding, because a line meant to demonstrate automated operation has to show its own state, its stops and its cycle results without an engineer at the screen. The site's automation solution category lists that demonstration line as its solution entry, with no figures published on the card, so the sensible treatment in an enquiry is to ask what the line records and displays rather than to assume what it can do.
Where PowerDe's own delivery process puts this decision
The engineering sequence published on the PowerDe customisation page runs from requirements communication through technical evaluation, scheme design, mechanical and electrical design, prototype or equipment manufacturing, test validation and delivery acceptance. Control system design appears inside the mechanical and electrical design step, which is where the control logic has already been described in the scheme design step. That ordering matters to a buyer, because the panel and the logic are settled on paper long before any screen is purchased, and an enquiry that arrives without a machine-state description forces that decision to be made during manufacturing, when it is expensive to change.
A customization enquiry can cover the same ground in either direction. The steam cleaning line on the customization page lists function module customization and control combinations such as water washing, steam, foam and dust collection on a mobile platform, while the automation line lists process planning, electrical control system design, PLC, HMI and motion control. A buyer who wants a cleaning machine with a recipe per surface type, or a station that records whether a cycle completed, is asking for integration; a buyer who wants the same machine with a different colour housing is not.
What to ask for when you specify it
- A machine state description written in words: running, paused, faulted, cleaning, setup, idle, and which transitions are allowed.
- A list of every fault the controller will report, each with a plain-language text and the sensor or condition that triggers it.
- A parameter list with three columns: the parameter, who is allowed to change it, and the upper and lower limits.
- The recipe contents, if the machine holds more than one job, and how a change is applied between cycles.
- The handshakes with upstream and downstream equipment, including what each side signals on stop, starve and block.
- Which values are recorded, for how long, and how they are exported, if traceability is part of acceptance.
- The programme ownership after acceptance: who holds the source, who can edit it, and what version is on the machine.
- The electrical drawings, input and output list, and the delivered programme, named as documents rather than implied.
The services behind that work package sit under non-standard automation equipment, since a panel designed around one process is not a catalogue item. The manufacturing automation page names process analysis reports, layout, drawings, schematics, PLC and HMI programmes, fixture drawings, bills of material, operating instructions, test reports and factory acceptance criteria among the deliverables. A specification that asks for those items by name is asking for an integrated system, because the panel cannot be accepted separately from the logic it displays.
How a buyer's own scope affects the decision
Some buyers already have the controller platform and the maintenance team to support it, and want the machine logic and screen built to their standard. Others want the equipment to arrive working and have no internal owner for the software. Those are different enquiries, and the second one carries training, spare parts and programme backup as items to agree, not assumptions. If your site has an existing standard for alarm naming, tag numbering or panel layout, sending it with the enquiry is faster than describing it later.
PowerDe's engineering pages describe work that starts from an idea, an existing product or a production line pain point rather than a finished drawing. That is where the integration decision belongs in a conversation: state the process, the people who will run it, and what has to be visible and recorded, then let the control architecture follow from that instead of naming a screen size in the first message.
A short check before you commit
Before the control scope is fixed, answer three things in writing. First, what does an operator need to know within five seconds of a stop? Second, what does a supervisor need to be able to prove about a completed job? Third, what does maintenance need to see that an operator should not change? If the three answers share a variable list, you have an integrated requirement and can price it as one work package. If they do not, you have a control box with a display on it, and the cost difference is worth knowing before the quotation arrives.
