Turn the HMI That Ships with a Standard Machine into a Product | OEM Standard-Machine Software
When an OEM ships a standard machine, the mechanical design can be copied by model. The supervisory software often stays a one-off project for that serial number. Screens run, the process runs — and the next unit is rebuilt almost from scratch. Once the machine is exported, every fault means a site visit. Moving core logic and algorithms from the PLC to the HMI, integrating control and supervision, then licensing by model so delivery can be replicated, is what makes batch cost, IP retention and productization possible. This article covers why OEMs productize the bundled software, which layers it must own, how one-off project software differs from standard-machine product software, and three items to lock before the machine leaves the country.
Why machine builders should productize the bundled software
The mechanical build of a standard machine copies from drawings and a bill of materials. If the software is still delivered as a project, every shipment reopens requirements, redraws screens and forks another version. Effort tracks unit count, and screens patched on site never return to the model baseline.
The sharper issue is where intellectual property sits. When process know-how and decision algorithms live only inside the PLC project, staff turnover or a change of contractor scatters that knowledge with the job. Move the core logic to the supervisory layer and keep control and management in one place, and the software can be licensed by model — a product that travels with the machine, not a one-off deliverable.
- Batch delivery is what spreads development cost: on multiple units of the same model, differences belong in configuration and licensing, not in rewriting screens
- IP stays with the software: recipes, interlocks and decision algorithms sit on the HMI side, where version control and license checks can actually run
- The machine brand is not dragged down by the shipped HMI: consistent operation and readable alarms are part of how the equipment is judged
- After-sales has to scale with shipments: once machines are sold abroad, flying someone out for every fault does not hold; remote-first diagnosis is required
For equipment OEMs, we treat the supervisory software that ships with a standard model as a replicable deliverable: core logic and algorithms move to the HMI side, control and supervision stay in one loop, and licensing is issued by model. Builders whose mechanical platform is already a product need the software layer on the same pattern before factory software stops being a project.
How far standard-machine software must reach: HMI, recipes, alarms, remote service
Standard-machine software is not “a few more operator screens.” To copy with the model and hand over under a license, the scope has to include the operator layer, the process layer, the exception layer and the after-sales layer. A missing layer rarely shows at shipment; it shows on the third unit or at an overseas plant.
- HMI: operator screens, permissions, the entry point for model changeover. Variants in the same series — different ratings or station layouts — should switch by configuration, not by a separate project
- Recipes: process parameters, interlock conditions, decision thresholds. Model differences go into recipe and configuration tables; changeover does not change code
- Alarms: classification, history, reset and archive. Remote after-sales must see what occurred and whether it returned to normal, not only a flashing screen on site
- Remote service: live data, history, alarms, audit, analysis. After-sales moves from mandatory travel to remote-first diagnosis, then a decision on whether to visit
Where one-off project software differs from standard-machine product software
Use the table below as a buying checklist. If the contract says “build a set for this site,” a polished screen set still leaves the next unit as another project. Acceptance for standard-machine product software should answer how the next unit of the same model is replicated, how licenses are issued, and how versions are taken back.
| Checkpoint | One-off project software | Standard-machine product software |
|---|---|---|
| Delivery | Customized per contract for that site, then closed | Bundled with a standard model and delivered by replication |
| Where logic lives | Process and algorithms mainly in the PLC | Core logic and algorithms move to the HMI; control and supervision in one loop |
| Cost shape | Effort re-estimated per unit; input rises roughly with unit count | Develop once, ship in volume; differences sit in configuration |
| Intellectual property | Engineering scattered across jobs and contractors | Software stays with the product and is licensed by model |
| After-sales | Screen changes assume a site visit | Remote diagnosis, configuration push, versions can be traced back |
Three items to lock before export: languages, remote service, licensing
Once a standard machine crosses a border with the equipment, software gaps are magnified by distance. A language mismatch, no remote path in, or licensing left unwritten all turn into a travel ticket. OEMs should put these three items into the technical agreement before the first export unit ships.
- Languages: keep UI strings and alarm text outside the screens. Cover at least the factory language plus English, and add the destination-market language. Maintain copy separately from layout so each language does not become its own project
- Remote service: agree a secure remote path (3G/4G/Ethernet and similar) and the readable scope for live data, history, alarms and audit. Diagnose remotely first, then decide whether to travel
- Licensing: issue by model and by unit; do not hand the full source tree to every site. Write the path for expiry and version upgrades so overseas channels cannot copy the engineering privately
Multi-screen SCADA bundled with foundry equipment and commissioned overseas is a usable reference: a European foundry-equipment builder had a localized casting-line SCADA (multi-screen) implemented with the machines at overseas plants. A standard machine only holds as an export product when multilingual screens and remote-first diagnosis are both in place. Requirements should be closed with an English-speaking contact so specification drift is caught before shipment.
Summary
Productizing standard-machine software is not about richer graphics. It is about placing core logic on the HMI, making delivery replicable, and tying licenses to the model. Once HMI, recipes, alarms and remote service are in scope, multilingual UI, the remote path and licensing have somewhere to land on export.
If a standard model is moving from “one project per machine” to “a product licensed by model,” start from the current factory screens, recipe tables and after-sales tickets, and first mark which layer is still stuck in project delivery.
Discuss the productization scope for bundled machine software
Tell us the model family, the factory-screen scope and the destination languages, and we will help draw the boundary across HMI, recipes, alarms and remote service.
Contact Us