A PLC and HMI integration sounds simple on paper: a controller from one vendor, a panel from another, a cable between them. In practice it is where many automation projects lose time, because the two halves are bought separately, documented separately and then tested together for the first time on the shop floor. If you are buying a machine, a retrofit or a production line from an integrator or OEM, the deliverables you ask for in the purchase document decide whether the handover is a two-day job or a two-week argument.
The list below is written for procurement and engineering buyers who need to specify what they are paying for. Every item can be turned into a line in your purchase order or a clause in the acceptance protocol, and each one has a reason behind it.
1. A written I/O list before anyone writes code
Ask for a signed I/O list as a design deliverable, not as a by-product of the code. It should give every input and output with its tag name, physical address on the PLC module, the field device it connects to, signal type (24 V digital, 4–20 mA, thermocouple, and so on) and fail-safe state. A single line that says "level sensor" without a signal type or an address is the most common cause of panel rewiring during commissioning.
A practical deliverable is a spreadsheet your maintenance team can keep using after the project ends, with columns for spare capacity. Request that at least one channel per card, or a defined spare percentage, is left physically wired and labelled, because future additions are cheaper when the terminal already exists.
2. A control narrative that a non-programmer can read
The narrative is a plain-language description of what the machine does, written section by section: start conditions, normal sequence, hold and pause behaviour, fault handling, manual mode, and what happens after a power loss. This is the document operators and shift supervisors can actually use, and it is the only place where intent is recorded. Ladder logic shows how; the narrative shows why.
Require that every interlock and alarm in the program appears in the narrative with the same name used on the HMI. When the naming is consistent across the I/O list, the PLC tags, the alarm list and the HMI screens, troubleshooting stops being a translation exercise.
3. PLC program with structure, comments and version control
Specify that you receive the complete, editable project file for the correct target and firmware version — not a read-only export. Then set expectations for its shape: a defined program structure with named function blocks per machine function, comments on every network or routine describing intent rather than restating the instruction, and a consistent tag naming convention applied throughout.
Two further deliverables are worth naming explicitly. First, a change log with a version number per release, so that the program loaded in the PLC can be matched to a document. Second, a documented password and access arrangement: who holds the download password, how a maintenance engineer obtains it, and confirmation that a password-free service route is not left open on the plant network.
4. HMI screen inventory and screen logic
Request the editable HMI project file for the exact runtime and panel firmware, plus a one-page screen inventory: screen name, purpose, who is allowed to open it, and which machine state it is available in. This small page is what makes training possible and reveals duplicated or dead screens before they are shipped.
Also require an alarm list with, for each alarm, the tag, the trigger condition, an operator-readable message, the recommended action and the responsible function. An alarm list of 300 entries that only says "sensor fault" transfers no knowledge to the night shift, while a well-written one with actions cuts mean-time-to-repair for the whole line.
5. Communication design, not just a cable
If the PLC and HMI come from different vendors — a very normal situation in retrofits — the interface definition is a real deliverable. Ask for a document stating the protocol (for example Modbus TCP, Profinet, EtherNet/IP or OPC UA), the device addresses and ports, the full tag or register map with data types and scaling, the update rate, and the timeout and reconnect behaviour. Then ask for the failure mode: what the operator sees and what the machine does when the link drops for two seconds versus two minutes.
Where the machine reports to a higher-level system such as an MES, a historian or an automated production line layer, request the same information for that interface at the same time. Retrofit projects usually fail here because the low-level integration was finished first and the upper interface was assumed.
6. Panel-level documentation that matches the hardware
The electrical drawings for the control panel must match what is inside the cabinet on the day it ships. The set should include the power distribution and circuit protection schedule, terminal and wire schedules, the PLC and HMI layout with addresses and switch settings, and the earthing and shielding arrangement for analogue and communication cables. If a device was substituted during build — a common event during component shortages — a revised drawing is a deliverable, not a courtesy.
7. A factory and site acceptance test you can sign against
Agree the test procedure before the build. A usable protocol lists each function to be proven, the input you will apply, the expected response, and a signature field. It should cover normal sequence, each interlock tripped one at a time, alarm behaviour, recovery after power loss and after an emergency stop, and manual-mode operation. For the PLC–HMI link specifically, include a deliberate communication-break test with the defined behaviour verified.
Two clauses matter commercially. State what happens if a test fails — who fixes it, who pays for the second visit, and what the retest window is. And state that the final payment release is tied to signed acceptance, with the documentation set listed as a condition of acceptance rather than a follow-up item.
8. Spares, firmware and lifecycle information
Ask for the exact order numbers of the PLC CPU, each I/O module, the HMI panel, power supply and fuses, together with the firmware and hardware revision of everything delivered. Add a written statement of the announced end-of-life or last-order date for the platform, if the vendor has one. Buying a controller line that is already obsolete locks your plant into a search for second-hand modules within a few years.
9. Backup and recovery, proven rather than promised
The deliverable is not "the program is backed up". It is a documented restore route: where the master project files live, the file naming convention for machine backups, the procedure to put a new panel into service, and one witnessed restore performed in front of your engineer before the project closes. A backup that has never been restored is untested.
For a plant with several lines, ask for a schedule: one numbered folder per machine with the PLC project, HMI project, drawings, alarm list and the released parameter sheet. This is what allows a shutdown fault to be handled by your own team instead of waiting for the integrator to fly in.
10. Training, spare-parts and after-sales terms in writing
Ask for on-site training against the delivered machine, not a generic course, with attendance recorded and materials that match the delivered revision. Agree response times for support, what remote access is permitted and how it is authorised, and the price and lead time for the recommended spares. These terms cost nothing to define at contract stage and become very expensive to negotiate after a breakdown.
How this connects to the equipment you are buying
The same discipline applies when the PLC and HMI sit on a piece of process equipment rather than on a production line. PowerDe builds cleaning and automation equipment where the control layer is part of the product: the Fixed Steam Cleaning Machine PowerDe HW02, for example, is a 220 V unit with 6 kW heating power, 160 °C steam temperature and 0.8 MPa vapour pressure in an 80 L SUS304 tank, with dry-steam, wet-steam and vacuum functions and leakage, short-circuit, high-temperature, high-voltage and water-shortage protection. A machine like that needs an HMI that shows heater state, temperature, pressure, tank level and each protection fault in a way an operator can act on, and a PLC program whose interlocks match the protection functions in the hardware.
If you are sourcing PowerDe cleaning equipment for your own product line or for a facility, the same document set should come with the machine: the I/O and alarm list, the parameter sheet of the released settings, the wiring drawing, and the spares list. Manufacturing automation work at PowerDe covers customised control and integration, so the deliverable list can be agreed at design stage instead of reconstructed after delivery.
A short checklist for your purchase document
- Signed I/O list with addresses, signal types, fail-safe states and documented spare channels
- Control narrative covering start, sequence, hold, fault, manual mode and power-loss recovery
- Editable PLC project for the correct target and firmware, structured, commented, versioned
- Editable HMI project plus screen inventory and a full alarm list with recommended actions
- Interface definition for every PLC–HMI and upper-level connection, including link-failure behaviour
- Panel drawings that match the shipped hardware, updated after any substitution
- Factory and site acceptance protocol with per-function pass criteria and a retest clause
- Order numbers, firmware and hardware revisions, and lifecycle statements for all modules
- Proven backup and restore procedure, witnessed once before closure
- Training against the delivered revision, spares pricing and support response terms
Ask for these items in the contract stage and the integration stops being an act of faith. Your maintenance team inherits a machine they can read, and acceptance becomes a checklist instead of a negotiation.
