HMI Screen Development in Thailand: RFP and FAT/SAT Guide

When a Thailand factory outsources HMI screen development, an RFQ based only on the number of screens and PLC tags may make prices look comparable, but it does not make completion criteria comparable. A usable HMI must help operators recognize equipment state, permit only authorized actions, guide abnormal response, remain clear in every required language, and recover from an approved backup. Those outcomes belong in one acceptance scope.

This guide turns that scope into practical requirements for factory managers, production and maintenance engineers, controls teams, procurement, and Japanese-headquarters approvers. It covers the HMI development boundary, an RFP matrix, deliverables, neutral vendor comparison, FAT/SAT tests, and a transparent workload model. It does not recommend a specific hardware brand. Features vary by model, license, software version, protocol, hardware, and deployment target, so compatibility must be verified before procurement.

What industrial HMI screen development actually includes

HMI means Human-Machine Interface: the operating point where a person sees equipment conditions, decides what to do, and issues permitted commands. Development is therefore more than drawing buttons. It includes the state model, display hierarchy, PLC and data boundary, alarms, user roles, languages, history, recipes, backup, change control, training, and acceptance.

This guide treats HMI work as an operating-interface lifecycle spanning design, implementation, operation, change, and recovery—not as a collection of screens. A buyer should specify who must decide what, in which operating scenario, from which data, with which authority, and how the result will be tested—not merely how many displays a vendor will draw. This is a practical procurement framework, not a substitute for any applicable standard.

Why a screen-count quotation fails

Two projects with twenty screens can require radically different work. One may show simple status. The other may include recipe change, audit trails, three languages, remote viewing, trends, permissions, and recovery. Screen count cannot express whether the project includes:

• normal production only, or also changeover, maintenance, manual operation, and abnormal recovery;
• a two-state run/stop model, or startup, waiting, interlock, fault, and recovery-confirmation states;
• alarm text only, or priority, cause, consequence, operator action, acknowledgement rights, and history;
• multilingual glossary ownership, fonts, input, text expansion, and approval;
• tag definition, scaling, data quality, update rate, and stale-data behavior;
• editable source, build procedure, licenses, version control, and tested restoration.

A low price per screen is not necessarily a low project cost. Omitted scope usually returns as a variation order, delayed startup, operating error, or an unrecoverable project file.

Make requirement-to-test traceability the core of the HMI RFP

The most valuable HMI procurement artifact is a traceable chain:

Operating scenario → equipment state → screen object → controller tag → permission → alarm/action → FAT/SAT evidence

For a “recover from conveyor jam” scenario, for example, connect the jam tag, visible state, stop reason, reset conditions, maintenance-only commands, related alarm, and recovery test under one requirement ID. When a condition changes, the impact can be found. At acceptance, the buyer can see whether every requirement has evidence.

Buyer’s HMI scope matrix

An effective RFP distinguishes information supplied by the buyer, design work owned by the integrator, and artifacts jointly approved. The following matrix can be used as a discovery checklist.

Define equipment state before selecting colors

A good interface lets an operator understand the current state, the reason for that state, and the next permitted action. Define production, standby, stopped, faulted, startup preparation, waiting for interlock, manual intervention, communication failure, and stale data where relevant. The exact list comes from the operating scenarios.

Color alone is fragile under glare, different displays, color-vision differences, and competing alarms. Combine color with shape, label, location, and carefully controlled animation. Keep normal conditions visually quiet and reserve strong emphasis for conditions requiring action. Record these rules in the HMI philosophy and style guide.

Industrial touch-panel design includes gloves and misoperation risk

Thailand production areas may involve gloves, heat, dust, reflections, standing operation, and language differences. Small touch targets, adjacent hazardous commands, or a prerequisite hidden below a scroll boundary may pass a desktop review but fail on site. Define target sizes and spacing, confirmation behavior, hold-to-act or two-step approval where appropriate, and the boundary between HMI commands and physical controls.

An HMI is not a safety function by itself. Safety-related logic and validation must remain in the appropriate safety system and be reviewed by qualified parties. The HMI can communicate safety status; it must not be presented as a substitute for a safety circuit.

HMI alarm design: optimize for action, not message count

An alarm list should not be treated as a list of controller messages. Alarm necessity, priority, expected response, implementation, testing, operational monitoring, change, and history all need explicit ownership. This guide translates that responsibility chain into RFP and acceptance-test requirements.

Each alarm should have, at minimum:

• unique ID, activation and return conditions, delay and deadband;
• priority and its documented basis;
• expected operator response;
• likely causes and places to inspect;
• consequence if no action is taken;
• roles allowed to acknowledge and the acknowledgement record;
• shelving, suppression, and maintenance-mode rules;
• FAT/SAT steps for activation, acknowledgement, return, and history.

If a state change only needs recording, classify it as an event. If it is informational and needs no response, use a message. Reserve alarms for conditions requiring timely operator action. Otherwise, important conditions disappear into alarm floods. Manage the alarm master separately from screen graphics and retain the change reason and approver.

Multilingual HMI rules for Japanese headquarters and Thai operators

Localization is not a last-minute string replacement. A short Japanese label can become much longer in Thai or English. Text can overflow buttons, tables, trends, and popups. Thai vowel and tone composition, Vietnamese diacritics, and long English compounds must be tested with the actual runtime and font.

A controlled glossary gives one approved term to each machine, state, and command. Approval should include the people who operate the equipment, not only a headquarters translator. The handover must also identify translation approvers, the change workflow, fallback language, string import/export, and how edited strings are re-imported into source control.

Multilingual acceptance should cover:

1. navigating every display in every language and recording overflow, overlap, and untranslated keys;
2. checking Thai and Vietnamese composition and, where input/search is required, correct data handling;
3. verifying language behavior in alarm history, trends, recipes, audit logs, and PDF/CSV output;
4. switching language during operation without corrupting state or partially entered values;
5. synchronizing glossary changes across screens, manuals, and training material.

Clarify PLC, tag, and data ownership

HMI and PLC software are tightly coupled, but a vague responsibility boundary stops troubleshooting. The tag dictionary should include logical name, PLC address, data type, unit, scaling, read/write direction, update rate, quality, owner, and consuming displays. Separate values calculated in the HMI, interlocks guaranteed by the PLC, and recipe data received from upstream systems.

If PLC modification is part of the work, treat source control, online change, rollback, I/O verification, and effects on the existing machine as a separate scope. Our guide to PLC program development outsourcing in Thailand explains this boundary. For aging equipment, combine it with the PLC replacement and retrofit guide to plan compatibility and downtime.

When communication is lost, the last good value must not look current. Distinguish stale, bad-quality, and disconnected data, and define when commands are inhibited. This is a decision-safety requirement, not a cosmetic preference.

HMI development deliverables

List deliverables in the purchase scope with format, language, editable source, and approver. A PDF alone is rarely sufficient for future modification.

Compare vendors by RFP compliance, not by brand ranking

Product information from Mitsubishi Electric GOT3000, Rockwell Automation FactoryTalk Optix, and Siemens WinCC Unified illustrates capabilities such as high-resolution visibility, multilingual graphics, alarms, version management, OPC UA, web clients, centralized deployment, and PLC-data connectivity. These are examples, not universal requirements or a guarantee for every model. Confirm the target model, license, version, protocol, and runtime.

Ask a vendor demonstration to include communication loss, a denied command, long Thai text, alarm load, and restoration—not only an attractive normal-production overview.

Include remote access and cybersecurity from the beginning

If the HMI connects to a plant network, historian, web client, cloud service, or remote support provider, the scope reaches the IT/OT boundary. CISA’s public ICS recommended-practice resources cover defense in depth, patch management, incident response, secure procurement language, and secure remote access. The RFP should define at least:

• named accounts and roles, including how shared administrator access is controlled;
• remote-access approval, time limits, multifactor authentication, and session records;
• permitted communication direction and ports among HMI, PLC, historian, and upstream systems;
• USB and file-transfer controls, malware checks, and application allow-listing procedures;
• patch responsibility and the test environment for OS, runtime, and project updates;
• backup encryption, location, retention, and recovery ownership;
• incident contacts, evidence preservation, isolation, and recovery procedures.

Whether remote control is allowed or remote viewing only is not merely a convenience decision. It requires hazard review, equipment safety design, site confirmation, latency and disconnection behavior, and qualified approval.

FAT/SAT acceptance tests for HMI development

FAT verifies the design in the development or pre-shipment environment. SAT verifies the integrated solution with the target controller, network, equipment, accounts, and site operating conditions. Define their boundary, test data, simulator, witnesses, evidence format, and retest rules before award.

Make abnormal recovery a formal acceptance condition

A normal-operation demonstration does not reveal operational weaknesses. Verify stale-data marking, restart behavior, incomplete recipe handling, acknowledgement history, and the ability to recover without an unsafe automatic action. Conduct every test under a risk-assessed and approved method.

A backup does not pass because a file exists. In a clean workstation or virtual environment, restore required software, licenses, communication settings, and project assets, then reproduce startup, edit, build, and—where safely permitted—download. Do not leave recovery dependent on one engineer’s memory.

For an integrated controls test strategy, see our sequence-control design and FAT guide. Use the same requirement IDs across PLC logic, HMI indication, I/O, and machine evidence.

A transparent hypothetical workload model

There is no universal market price for HMI development. Work varies with tags, scenarios, alarm rationalization, languages, runtime, controller interface, recipes, reports, FAT/SAT, training, documentation, and source handover. The following is a hypothetical planning calculation, not a market quotation or a TOMAS TECH estimate.

Assume one new line, 12 main screens, 8 popups, 300 PLC tags, 60 alarms, three languages, no existing style guide, one FAT, and one SAT.

The 56 person-days are only transparent assumptions. The useful comparison is what each bidder includes, which inputs remain the buyer’s responsibility, and how retest and site waiting are treated. Converting a “20 screens” price into work packages exposes these differences.

Assess changes by the affected requirement IDs and their screens, tags, languages, alarms, documents, and retests. A label edit and a change to state transition or permission should not be treated as equivalent work.

Thailand-site risks and controls

Three-party approval across headquarters, site, and integrator

Where headquarters defines policy, the Thai site accepts the equipment, and an integrator implements it, unclear approval causes delay. Assign author, reviewer, and approver at each gate: requirements, glossary, prototype, alarms, FAT, and SAT. Headquarters may own machine policy, operators usability, controls the PLC boundary, and IT the network and accounts.

Limited downtime for live tests

An existing line cannot freely generate every fault. Agree the shutdown window, simulator substitutions, residual risk of unperformed tests, and later retest condition. Online changes require a backup, reviewed difference, rollback, and site authorization.

License and maintenance-account risk

A project may run on the developer’s PC but fail at the site because runtime, driver, web-client, historian, or language licenses are missing. Record product identifier, quantity, contract owner, renewal, offline behavior, and replacement transfer in the build/version manifest. Recovery must not depend only on a vendor employee’s personal account.

Conditional treatment of Thailand BOI eligibility

Thailand BOI’s current Investment Promotion Guide lists activities involving automation machinery or equipment with engineering design, automation-system integration, and control-system configuration. That does not mean an individual HMI project automatically qualifies. Entity, activity, equipment, application timing, and other facts require case-by-case confirmation with BOI or an appropriate adviser.

Practical HMI development sequence

1. Observe work and define scenarios: include shift operation, changeover, cleaning, maintenance, and recovery.
2. Approve the HMI philosophy: agree states, hierarchy, colors, components, commands, alarms, and languages using samples.
3. Build traceability and prototype: connect requirements, tags, permissions, alarms, and tests before full implementation.
4. Implement iteratively: start with reusable components and representative scenarios; review with site-language speakers.
5. Perform FAT: simulate normal, abnormal, communication, permission, language, and recovery conditions.
6. Perform SAT: use real PLCs, I/O, network, accounts, and site conditions.
7. Train and hand over: separate operator, maintenance, administrator, and change-control training; demonstrate restoration.
8. Control changes: retain requirement ID, version, reason, approval, and retest evidence after startup.

FAQ about HMI screen development

Is HMI screen development only touch-panel layout design?

No. Layout is one component. A complete scope covers operating scenarios, state, controller tags, permissions, alarms, languages, history, remote access, backup, FAT/SAT, training, and editable-source handover.

Can HMI development cost be compared by price per screen?

Not reliably. Tag behavior, dynamic objects, recipes, reports, alarms, localization, permissions, communication, tests, and documentation can make equal screen counts require different effort. Compare normalized work packages, assumptions, exclusions, retest, and site support.

What should be decided first in industrial touch-panel design?

Define users, operating scenarios, equipment states, permitted commands, and abnormal actions before colors and widgets. Then design hierarchy, navigation, reusable objects, and visual rules.

What should an HMI alarm-design deliverable contain?

Require an alarm master with priority basis, cause, consequence, operator response, acknowledgement rights, suppression rules, history, FAT/SAT steps, and change record. Rationalize whether every proposed alarm genuinely requires action.

Should PLC software and HMI development be outsourced to one company?

One company can simplify ownership, but it is not mandatory. With separate suppliers, define the state model, tag dictionary, cause-and-effect references, version control, integration test, and troubleshooting ownership in the RFP.

Which matters more for equipment startup support, FAT or SAT?

Both. FAT finds design defects while changes are easier; SAT verifies the real machine, network, accounts, and operators. SAT-only concentrates defects during downtime, while FAT-only misses site integration differences.

Can an HMI be used as a safety function?

The HMI can support awareness but is not a substitute for the appropriate safety system. Safety logic, circuits, stop functions, and validation require qualified review based on applicable standards and risk assessment.

Is handover complete when the buyer receives source files?

No. The buyer also needs software and versions, licenses, drivers, communication settings, build instructions, checksums, backups, and a demonstrated clean restore. A buyer-side engineer should open, build, and make a controlled minor edit.

Conclusion: accept an operating interface, not a set of screens

HMI screen development quality cannot be measured by appearance or screen count alone. Trace operating scenarios through states, screen objects, PLC tags, permissions, alarms, languages, restoration, and test evidence. Prove abnormal behavior, localization, communication loss, restart, and clean backup restoration in FAT/SAT. An RFP should also define deliverables, ownership boundaries, versions, licenses, source ownership, and change control so that vendors are compared on the same basis.

If you are planning an HMI project for a Thailand factory, you can discuss the scope even before the screen inventory and tag list are complete. TOMAS TECH can help structure site scenarios, an RFP boundary, and FAT/SAT acceptance conditions. Share the equipment type, existing PLC, required languages, and target startup period through our contact page.

Primary references

• Mitsubishi Electric GOT3000
• Rockwell Automation FactoryTalk Optix
• Siemens WinCC Unified for Industrial Edge
• CISA ICS Recommended Practices
• Thailand BOI Investment Promotion Guide