When you outsource touch panel HMI screen design, quotes from three vendors can differ by nearly a factor of two even though every vendor received the same machine, the same PLC and the same screen count. The root cause is that the work is ordered as if it were “drawing screens.” In reality, four layers are settled before anyone opens the drawing tool: information design, alarm design, language and permissions, and the data exit. Which of those layers you decided in-house determines both the price and whether operators actually use the screen. This article puts those four layers into plain language, from the perspective of a plant in Thailand.
HMI Screen Design Is 90 Percent Decided Before Anyone Draws a Screen
Ask plants that have just requested “a touch panel screen, please” from a machine builder or a software house to explain the basis of the quote they received, and very few can. Most buyers assume the number is screen count multiplied by a unit rate. Then they invite three vendors, and the spread can come back close to 2x — for the same machine, the same PLC, the same screen count.
That spread is not a difference in hourly rates. It is a difference in how far each vendor looked into the question “what has to be decided before this can be built?” Drawing the screens is, in fact, not where the hours go. The hours are set by design decisions: what appears on the screen and what does not, which PLC bits are escalated to a human as alarms, who is allowed to perform which operation, and where the numbers displayed on the screen are ultimately stored. When those decisions arrive undecided, the development side has to “decide while building,” and it prices that risk. When they arrive as a written specification, drawing becomes close to mechanical work. So when quotes diverge, the expensive vendor is often not overcharging — it has simply priced in the assumption that it will have to make your decisions for you.
This structure lines up with how the international standards treat HMIs. ISA-101.01-2015, together with the technical reports ISA-TR101.01-2022 (HMI Philosophy) and ISA-TR101.02-2019 (Usability and Performance), treats the HMI not as a deliverable made of screens but as a lifecycle covering design, implementation, operation and continuous improvement. Its scope is not limited to continuous process plants; it applies to continuous, batch and discrete manufacturing alike. In August 2024, IEC 63303 Edition 1.0 was published as the international standard built on ANSI/ISA-101.01. Developed by WG19 under IEC TC65/SC65A, it defines the full HMI lifecycle from concept through decommissioning, the terminology and models, and the work processes required to keep an HMI maintained. In other words, the standards themselves say an HMI is not something you build, hand over and forget; it is something you operate and maintain.
Here are the four layers this article works through. Each following section expands one row of this table.
| Layer | What gets decided | What happens on the floor if you skip it |
|---|---|---|
| Layer 1 Information design | What is not shown during normal operation; screen hierarchy and navigation; the always-visible indicators | Every available data point lands on one screen and abnormalities disappear into the background. Operators stop looking at the screen |
| Layer 2 Alarm design | Which bits are escalated to a human, and who does what; priority distribution and rate limits | Alarms sound continuously and nobody responds. The one alarm that mattered is lost in a flood |
| Layer 3 Language and permissions | Who performs which operation, in which language; display language and access rights | Local operators cannot use the machine, and the engineering team is permanently tied to the equipment |
| Layer 4 The data exit | Whether values stay in the HMI or go to MES/IoT; retention period and retrieval method | Data exists only on the screen, so defects and minor stoppages cannot be traced afterwards |
A fifth axis runs across all of them: where to draw the boundary between in-house work and outsourced work. The position taken here is that what belongs in-house is the specification, not the drawing. That line matters most in environments like a Thai plant, where engineering resources are thin and equipment turns over quickly.
What Is an HMI? Redrawing the Line Between Touch Panel, SCADA and Andon
The first obstacle in industrial HMI design is vocabulary. If “touch panel,” “HMI,” “SCADA” and “andon” are used interchangeably inside your organization, the specification you hand to a vendor will mix them too. These four things sit in different physical places and carry different responsibilities.
| Term | Physical location | Primary role | Who looks at it | Impact when it fails |
|---|---|---|---|---|
| Touch panel (HMI display) | Machine operator station, control panel door | Operating, setting, status display and alarm display for that machine | Machine operator, changeover staff, maintenance | The machine cannot be operated. Production stops |
| SCADA / supervisory system | Office or control room PC | Centralized monitoring of multiple machines and lines, trends, history | Production control, production engineering, plant manager | Monitoring is lost, but the machines keep running |
| Andon | Above the line, visible from the aisle | Communicates current state at a glance from a distance | Anyone passing by, team leaders, floating support staff | Calls for help are delayed. Downtime lengthens |
| PLC | Inside the control panel | The actual control logic and I/O handling | Nobody looks at it directly | The machine itself does not run |
When this distinction is blurry, a predictable distortion shows up in the specification. The most common one is loading SCADA responsibilities onto the touch panel: monthly production trend charts on the machine’s operator station, status of other lines, product master maintenance. Screen count balloons, the panel’s processing power and memory get squeezed, and the operating functions that actually matter become sluggish. The mirror-image failure also happens: information that an andon could have communicated across the shop floor is buried where you must walk up to the panel to see it.
The decision rule is simple. Place information according to where the person who needs it is standing. What a person standing in front of the machine needs right now goes on the touch panel. What someone needs to know from a distance goes on the andon. What someone will want to review as a trend later goes to SCADA or an upper-level system. Do this separation first and screen count drops visibly.
One related point: pushing a notification to a responsible person when something goes wrong is a different domain from screen design. How to cover the hours when nobody is standing at the machine, or night shifts running thin, belongs to the discussion of equipment alert and notification systems. Flashing red on the HMI and delivering a message to a supervisor’s phone are two different designs. Lumping both under “alarm handling” is what makes the Layer 2 discussion go vague.
Layer 1 | Information Design: Decide What Not to Show During Normal Operation
What gets decided
Layer 1 defines the structure of the screens: the hierarchy, the information carried by each screen, and the elements that are always visible.
The most important decision here is subtractive, not additive. You are deciding not “what to show” but what not to show during normal operation. This thinking comes from the design philosophy known as High Performance HMI, grounded in research from the ASM Consortium and carried into ISA-101. Its core idea is report by exception. In normal operation the screen does nothing more than communicate, at minimal cognitive load, that everything is within expected bounds; only at the moment a value leaves its expected operating range does the screen present that fact in a form that cannot be missed. With this design, operators no longer have to read the screen continuously — they only have to direct attention when something changes.
The hierarchy is generally built in four levels. At the top, plant or line overview state. Next, the operating screen for a machine or unit. Below that, detailed setpoints and trends. At the bottom, diagnostic and maintenance screens for individual devices. Operators live in the top two levels day to day; the rest just needs to be reachable when required. Deciding this hierarchy in advance removes the case-by-case argument about “which screen should this piece of information go on?”
What happens if you skip it
Order without doing information design and you will almost certainly receive an “everything on it” screen. Every value the PLC holds becomes a numeric field, every sensor is drawn as an indicator lamp on top of the machine outline, and any leftover space is filled with temperature and pressure trends. The designer intends this as thoroughness. The floor experiences the opposite.
On a screen where information is spread evenly, an abnormality does not stand out when it occurs. If one lamp out of forty changes color, people do not detect it. Operators stop looking at the screen and start judging the machine by physical signals instead — unusual noise, a jam in the conveyor. The screen you paid for becomes functionally equivalent to having no screen.
A second symptom is color saturation. Draw the whole machine in vivid colors, apply green for running and blue for standby to every device, and there is no attention-grabbing color left. Show red for an abnormality and it is absorbed by the red decoration already on the screen. High Performance HMI design keeps the normal-state screen close to grayscale with low saturation and reserves high-saturation color exclusively for deviation. Because this looks plain, the first management review often calls it “empty” — and that judgment reliably reverses once the machine is in production.
How to write it in the specification
You do not need to draw screen mockups to communicate information design. Four written items are enough.
| Item | Example wording |
|---|---|
| Screen hierarchy | Four levels: plant overview / machine operation / detailed setpoints and trends / maintenance diagnostics. Routine operator tasks must be completable within the top two levels |
| Always-visible elements | A header common to all screens shows operating mode, current product, the highest-priority active alarm, and time |
| What is hidden in normal operation | Individual sensor states are not shown in normal operation. They live on detail screens and are promoted to the operating screen only on abnormality |
| Color policy | Normal state is composed at low saturation. High-saturation color is reserved for deviation. Steady green is not used to mean “normal” |
Those four lines are enough to fix the vendor’s drawing policy. Without them, “please make it easy to read” leaves the definition of readability to one developer’s personal taste.
Layer 2 | HMI Alarm Management: A Screen That Alarms Constantly Is the Same as No Screen
What gets decided
Layer 2 decides which of the fault bits held in the PLC are escalated to a human — and, for each one that is, who does what.
A typical machine carries several hundred to several thousand fault bits in the PLC: sensor wire breaks, limit switches not made, servo alarms, inverter overloads, communication timeouts. Dump all of them mechanically into the HMI alarm list and alarms stop being information and become noise. Layer 2 design means stopping that dump and passing each candidate through a judgment.
There is a single criterion. When this alarm appears, is there an action a person must take? An alarm with no action is not an alarm. It may be worth logging, but there is no reason to interrupt the operator’s screen with it. Shifting the standard from “we alarm because the data is available” to “we alarm because a human needs to act” is the whole substance of this layer.
Put quantitative targets in the specification
HMI alarm management has quantitative references you can cite. It is easiest to understand the relationship this way: ISA-18.2 lays out the alarm management framework qualitatively, and EEMUA 191 supplies the corresponding quantitative benchmarks. The headline figures:
| Metric | Benchmark | Meaning |
|---|---|---|
| Steady-state alarm rate | Fewer than 1 alarm per 10 minutes per operator (roughly 150 per day as a guide) | Above this, the operator cannot make time to handle alarms one by one |
| Peak rate during an upset | Fewer than 10 alarms per 10 minutes | Even immediately after trouble, design so the rate stays inside this range |
| Definition of alarm flood | More than 10 alarms in 10 minutes (ISA-18.2) | In flood conditions, identifying the one alarm that matters becomes practically impossible |
| Standing alarms | Fewer than 10 per operator | Many permanently active alarms keep the list red, so new events are buried |
| Priority distribution | High 5% / Medium 15% / Low 80% | Too many high-priority alarms erase the meaning of priority |
| Chattering alarms | Eliminate | Alarms that repeatedly cycle on and off occupy the list and push everything else out |
The sources are exida’s summary of alarm management standards and Emerson’s “Alarm Management by the Numbers.” These figures were developed primarily with continuous process industries in mind, but the underlying premise — there is an upper limit to how many alarms an operator can process — holds just as firmly for a discrete manufacturing machine HMI. Whether you write the numbers into the contract depends on the nature of the equipment; but even holding them as design targets pulls the alarm definition discussion out of the realm of opinion.
What happens if you skip it
Machines built without alarm design fail in a consistent sequence.
First comes the flood during commissioning. A machine under adjustment brushes thresholds all over, so the alarm list fills. At this point the floor decides “it’s commissioning, that’s normal” and starts a practice of pressing reset without reading the list. Second, that practice sets. Alarms do not decrease once volume production starts, and pressing to clear becomes a habit. Finally, the same reflex is applied when an alarm that genuinely requires action appears. That is alarm fatigue.
At a plant in Thailand the sequence can run one step faster. If alarm messages remain in the head-office language or in English, local operators cannot read them at all. You cannot make a judgment about something you cannot read, so from day one there is no option other than “press and clear.” When a Layer 2 failure lands on top of an unaddressed Layer 3, the alarm function is dead from the moment the machine starts.
The same failure comes back to bite when you try to analyze minor stoppages — the situation where the machine is not visibly down, yet output does not reach target. If the alarm history is a list of “pressed and cleared” records, stoppage causes cannot be classified. The breakdown of stoppage causes discussed in minor stoppage countermeasures and OEE assumes each alarm was defined with meaning, one at a time.
How to write it in the specification: the seven rationalization fields
Alarm rationalization means taking each alarm candidate and documenting it. Seven fields per alarm:
| Field | Content | What good input looks like |
|---|---|---|
| Tag name | The PLC device or tag identifier | Fix a naming convention that is unique within the machine before you start |
| Description | What happened, written in the words of the person who must act | Not “M120 ON” but “Infeed conveyor: material jam” |
| Cause | The likely causes | Workpiece tilted, dirty sensor, oversupply from the upstream process |
| Consequence | What happens if it is left alone | Downstream process runs empty. The whole line stops within 3 minutes |
| Operator action | Who does what, in what order | Operator opens the guard door, clears the jam, presses reset |
| Priority | High, medium or low | Decided against the distribution above (5% / 15% / 80%) |
| Acknowledgement | Whether acknowledgement is required, or auto-return is acceptable | Whether it stays in history after return, or may clear without acknowledgement |
The vendor cannot fill these in alone. Only the party that runs the machine can write cause, consequence and action. Which means the reverse is also true: if you build this table and hand it over, the vendor’s job reduces to translating it into screens and logic, and the uncertainty in the quote drops sharply. Alarm definition count is one of the main quote drivers, as covered below — but who writes the definitions changes the character of the number.
In practice, filling seven fields for every bit is too heavy. The workable approach is to first sort every bit into three buckets — escalate to a human / log only / do not surface in the HMI — and write the seven fields only for the first bucket. That sorting alone dramatically reduces what flows into the alarm list.
Layer 3 | HMI Multilingual Support and Operator Permissions
What gets decided
Layer 3 decides who performs which operation, in which language. Multilingual support and permission design look like separate topics, but in practice they hold together better in one layer. The reason is simple: both answers come from the same question — who is standing in front of this screen?
When a machine designed at head office arrives at a plant in Thailand, the screens usually arrive unchanged. Sometimes still in the head-office language, sometimes with English added. The unstated assumption is that the person operating the machine reads that language. Very few plants actually satisfy that assumption.
What happens if you skip it
When the assumption breaks, the symptom appears as engineers being permanently tied to the equipment. Every product changeover, every setpoint entry, every alarm brings a call to an expatriate engineer or the one local staff member who reads the source language. The hours consumed scale with the number of machines and crowd out everything else that person should be doing. And the moment that person takes leave or rotates home, nobody can change a setting on that machine.
This symptom is getting more serious as labor conditions in Thailand shift. According to JETRO survey data, wage increase rates at Japanese-affiliated companies in Thailand ran at 3.8% in 2023 and 4.58% in 2024, with 4.64% projected for 2025 — a widening annual increase. The same survey puts the perceived shortage of manufacturing workers at 42.3%. The harder it becomes to secure people, the more you need to widen the range of tasks your existing operators can cover. If the machine screens remain unreadable to them, operators stay locked at “can run it, cannot set it up,” and the plant as a whole loses flexibility.
Assume a steady rate of operator turnover and a second issue appears: training cost. If the screen is in the local language, handing over to a new operator can be done by walking through the screen. On a screen in an unreadable language, training degrades into memorizing “this button, in this position” — and any change to the layout forces retraining.
Practical multilingual support: switching methods and typography
“Multilingual” covers a range of implementations.
| Method | What it is | When it fits | Watch out for |
|---|---|---|---|
| Single fixed language | Built in the local language only | Operators come from a single language group | Unreadable during visits by head-office staff or remote support |
| On-screen language switching | A button changes the display language | Multiple language groups use the same machine | All text must be held per language. Frames must be sized for the longest language |
| Dual labeling | Two languages on one label | Simple machines with few labels | The screen becomes cramped. Not suitable for alarm messages |
| Login-linked | Display follows the logged-in user’s language setting | Operated together with permission design | Requires permission design. Must be decided together with the rest of Layer 3 |
Once the method is chosen, the typography work begins. This is where designers who have only ever worked in one language miss the most.
First, text width. A term that fits in four characters in an East Asian language becomes EMERGENCY STOP in English and yet another length again in Thai or Vietnamese. Size button and label frames to the source language’s character count and text will overflow, or collapse into an unreadably small font, the instant somebody switches. Size frames against the longest language.
Second, Thai line height. Thai script carries tone marks and vowel marks above and below the baseline, so it needs more vertical space at the same font size. A layout with line spacing tightened for a compact source language will clip the marks above and below. A missing mark makes a different word — so this is a meaning problem, not a cosmetic one.
Third, Vietnamese diacritics. If tone marks drop, the meaning changes. Some fonts do not render parts of the marks correctly, so verifying the display on the actual touch panel hardware must be an acceptance test item. Text that looks correct on the developer’s PC can break in the panel’s own font.
Fourth, the style of alarm messages. Outsource translation and you get back a literal rendering of the source text. If the “operator action” you defined in Layer 2 is not present in the source, translating it will not make the action clear. Treat localization not as translation work but as redesigning sentences that communicate an action, and the result changes.
Permission design
Permissions are not better for being subdivided into as many roles as exist. Too fine and they stop being used, and everyone reverts to sharing the administrator account. Three to four levels is the practical range.
| Level | Intended user | Can do | Cannot do |
|---|---|---|---|
| Operation | Line operator | Start/stop, product selection, alarm acknowledgement, normal reset | Change setpoints, disable interlocks |
| Setup | Team leader, changeover staff | Recall and fine-tune product conditions, home the axes after jig changes | Create new product masters, change safety-related settings |
| Maintenance | Maintenance, production engineering | Manual operation, I/O monitor, parameter changes | User management, deleting audit logs |
| Administration | Production engineering lead, equipment owner | User registration, product master creation, upper-level connection settings | Deleting audit logs (set as non-deletable at every level) |
If you design permissions, decide the operation log policy at the same time. Without a record of who changed what and when, a defect that appears after a condition change cannot be traced back through the change history. Logging is also a line item that affects the quote, so state whether it is required at specification stage.
How to write it in the specification
Hand over Layer 3 in five parts. One, the supported languages and their priority, including which is the default. Two, the switching method — button or login-linked. Three, the permission level definitions and the list of screens and fields each level may operate. Four, whether operation logging is required and for how long records are retained. Five, a requirement that display verification on the actual panel is part of acceptance testing. With those five, the vendor can pin down the effort for language and permissions.
Layer 4 | The Data Exit: Keep It in the HMI, or Send It to MES and IoT?
What gets decided
Layer 4 decides where the numbers shown on the screen are stored, and how anyone retrieves them.
Touch panels themselves can store data. Logging functions retain value histories, the panel holds alarm history, and the panel writes CSV out to an SD card or USB drive. Because those functions exist, plants often conclude “the HMI records it, so that is enough.” That conclusion has three blind spots.
First, capacity and retention. Internal HMI storage is limited and overwrites oldest-first. A request to check the operating conditions used for the same product six months ago cannot be met. Second, retrieval effort. To look at the data you have to walk to the machine and insert media. A routine of collecting data monthly from ten machines does not survive contact with reality. Third, no cross-machine correlation. Placing process A’s temperature next to process B’s defect rate is impossible as long as data stays locked inside each machine.
What happens if you skip it
Plants that installed equipment without settling Layer 4 end up in a steady state of “the data must be in there somewhere, but we cannot produce it when asked.” A quality issue occurs, head office asks for the operating conditions on that machine on that date, and somebody walks to the machine, inserts media, opens a CSV and hunts for the timestamp. As machine count and product variety grow, that becomes unworkable.
The second symptom is a reversion to paper. Because data is hard to get out of the HMI, operators end up transcribing on-screen values onto paper forms. The paper is filed at month end and never used for analysis. A large share of the situations that lead a plant to evaluate replacing paper with electronic forms begin exactly here: the data is in the HMI, and people are writing it on paper. Settle Layer 4 at machine design stage and the transcription never starts.
How to write it in the specification: the placement decision table
Decide placement per data type. Not everything needs to go upstream.
| Data type | May stay inside the HMI? | Value of sending it up | Rule of thumb |
|---|---|---|---|
| Live values (temperature, pressure, position) | Yes | Send if you intend trend analysis | If you want early warning of deviation, fix a sampling interval. There is no need to send every point at high frequency |
| Alarm history | No | High. Directly feeds stoppage cause analysis | Send occurrence time, return time, tag and priority as a set |
| Running / stopped state | No | High. Required to calculate OEE | Sending only state transitions is usually sufficient |
| Production and defect counts | No | High. Reconciled against production control records | Always attach product and lot identifiers |
| Operating conditions / recipes | Depends | Send if used to trace quality issues | Send at the moment a change occurs |
| Detailed maintenance diagnostics | Yes | Low. Viewing on site when needed is enough | Sending spikes data volume for little use |
For every item marked “send,” write the destination and the path into the specification as well. The upstream connection method — OPC UA, MQTT, direct database writes, via a gateway — depends on both the HMI model and what the receiving system accepts. Leave it entirely to the machine builder and the method varies machine by machine, adding conversion work later when you try to consolidate. It is worth restating your plant-wide standard method in every machine order.
Note also that sending data upstream means the control network now touches the information network. How that junction is designed belongs to OT security for factories. Decide the network segmentation policy at the same time you decide Layer 4, or you will be sent back later with “we cannot connect this for security reasons.”
Six Cost Drivers That Make HMI Screen Development Quotes Diverge
Quotes usually arrive as a single lump sum. Ask for the breakdown and it becomes clear what you are actually comparing. This article gives no absolute figures: cost varies widely with screen count, machine character and whether there is upstream integration, and no defensible universal rate exists. Instead, work with the factors that move the number.
| Line item | What moves the price | What you can do before ordering |
|---|---|---|
| Screen count and screen type | A simple display screen, a setting screen with conditional entry, and a trend screen differ by several times in effort. A raw screen count is useless for comparison | Classify screens into display-only / with operations / settings and masters / trends and history, and give counts per class |
| Tag count and PLC interface | The number of devices exchanged between HMI and PLC, and whether address allocation is organized. No naming convention means added reverse-engineering hours | Hand over an address list with device comments up front. Fix the naming convention on your side |
| Alarm definition count | Who writes the seven fields from Layer 2. If the vendor is expected to work out cause and action, review and rework hours get priced in | Build and hand over a rationalized alarm list. At minimum complete the three-bucket sorting |
| Number of languages | The count matters less than who supplies the translation and how it is accepted. Delegating translation to the vendor creates quality-review round trips | Supply translations yourself with a glossary. Fix the on-hardware verification procedure |
| Permissions and audit logs | User management, per-level screen control, log storage and retrieval. An undecided Layer 3 turns into a change order later | Provide the number of permission levels and the operation matrix per level. State whether logging is required and the retention period |
| Upstream integration | Connection method, transmitted items, transmission interval, behavior on link loss. Hours to verify the counterpart system’s specification are hard to read | Specify the item list and the connection method. Hand over the counterpart’s specification at the same time |
What these six have in common is that only the buyer can decide them. The vendor can independently decide the fine detail of drawing and nothing else; everything else is waiting on your decisions. When quotes diverge, the expensive vendor is pricing in waiting time and the risk that decisions never arrive.
If you do need an order-of-magnitude figure, insist it be framed as an estimate with stated assumptions. Ask, for example, what the effort would be assuming 10 display-only screens, 5 operating screens, 3 setting screens, 80 alarm definitions, 3 languages and no upstream integration. A number without assumptions is useless for comparison and useless for budgeting. A number built on stated assumptions lets you discuss which assumption to remove and how the figure responds.
The In-House / Outsourcing Boundary: Keep the Specification, Not the Drawing
“Should we get to the point where we can build HMI screens ourselves?” comes up at almost every plant at least once. The drawing software is obtainable and, with practice, screens can be drawn.
The short answer is that what belongs in-house is the specification, not the drawing. Three reasons.
First, drawing is a domain where productivity scales steeply with practice. Someone who touches the tool a few times a year and a developer who uses it daily take very different amounts of time to produce the same screen. Maintaining drawing skill at a plant that installs a handful of machines a year does not pay for itself.
Second, it is a high key-person-risk activity. Drawing completes as an individual task, so when the person transfers or resigns, nobody can open the project file. The machine keeps running, so the problem only surfaces years later.
Third — and this matters most — the ability to decide the specification cannot be outsourced at all. As Layers 1 through 4 have shown, every input to those decisions lives on the floor. Who stands in front of the machine, how each alarm should be answered, which data will be needed later. An external developer has no way to know.
There is, however, work worth keeping in-house. Minor edits to existing screens (label wording, threshold values), registering data for additional products, backing up and restoring screens. These are frequent enough that outsourcing them costs more in waiting than in money. At machine installation, arrange to receive the project files and procedure documents so this range of work is possible, and designate at least two people who can do it.
| Task | Keep in-house | Outsource | Reason |
|---|---|---|---|
| Deciding the four-layer specification | Yes | — | The inputs exist only on the floor |
| The seven alarm rationalization fields | Yes | — | Only the operating side can write cause, consequence and action |
| Translation and glossary | Yes | — | Only the plant holds the vocabulary local operators actually use |
| Creating new screens | — | Yes | Productivity difference from practice is large |
| PLC interface logic | — | Yes | Inseparable from PLC design. Splitting it blurs responsibility |
| Minor wording and value changes | Yes | — | Frequent; waiting time is the real loss |
| Project file management | Yes | — | The machine can outlive the relationship with the vendor |
A word on split ordering. The PLC program and the HMI screens can technically go to different companies. But if you split them, the boundary must be fixed as a specification: the list of shared device addresses, the meaning of each bit and word, and which side writes and which side reads. Split without that boundary specification and, when a fault appears, both parties will insist it is the other side’s problem while isolation eats the schedule. The approach to handing over specifications described in outsourcing PLC program development applies unchanged when the HMI is ordered separately.
Furthermore, if you are adding an HMI to existing equipment rather than commissioning a new machine, control panel modification comes with it: the panel cutout, power supply, space inside the enclosure, cable routing. That is separate construction work with a separate quote. Fixing the scope of panel modification first, from the perspective of control panel design and manufacturing, lets you align the HMI order with the panel schedule.
What to Watch When You Order in Thailand
Local build and commissioning support
Ordering HMI screen development in Thailand presents a choice: give it to a local system integrator, or have the machine builder include it. That decision is not made on unit rate.
Including it with the machine builder gives high consistency, because the screens are designed together with the machine control. The cost is that every post-commissioning change requires either a trip from the builder’s country or a scheduled remote session. Plants that wait several weeks for every added product variant are not unusual.
Giving it to a local integrator makes the change cycle fast and puts people on the floor during commissioning. The cost is the effort to reverse-engineer the machine builder’s control specification, and a boundary with the PLC side that tends to blur.
The realistic answer is a split: order new machines with the screens included by the builder, and place post-commissioning modification, localization and upstream integration with a local partner. For that split to work, the machine purchase contract must include receiving the project files and design documentation. If the contract does not entitle you to the source, nobody can touch it afterwards. That one clause belongs in every machine specification you issue.
Fix the scope of commissioning support up front
When you request equipment commissioning support with a vague scope, you end up negotiating extra charges. State at least the following at order stage: number of attendance days and the shift hours covered, whether attendance continues after volume production starts, whether operator training is delivered and in which language, response time for defect handling, and the warranty period and the date it starts from. Training in particular needs to be pinned down — who trains whom, in what language. Otherwise an explanation in the source language gets relayed through an interpreter and the content thins out.
BOI and the investment case
Automation investment in Thailand has an investment promotion framework from the BOI (Thailand Board of Investment). The BOI operates promotion measures for the automation machinery and robotics industries, with eligible activities and conditions published. HMI screen design on its own will not necessarily qualify, but where it sits as part of installing automation equipment or upgrading existing equipment, it is worth examining. Eligibility depends on the business activity and on the framework in force at the time of application, so checking early in the investment plan can change how you assemble the equipment specification.
For context, Thai manufacturing faces a structural push toward higher value-added operations. JETRO, analyzing shifts in trade and investment structure, points to the need for Thai manufacturing to move up the value chain. Putting machine operation in the hands of local operators is one concrete implementation of that shift. The multilingual and permission design covered in Layer 3 is a labor measure, but it is equally a way to lift the technical capability of the site.
Network and security
If you chose upstream integration in Layer 4, you need a path between the machine and the upper-level system. Where machine positions may change, or where cable installation is difficult in certain areas, wireless enters the discussion. Factory wireless, however, starts from different premises than office wireless: reflection off metal fixtures, blocking by moving objects such as forklifts, interference with existing equipment. The design cautions covered in industrial wireless LAN for factories apply directly when machine data rides on wireless.
And to repeat: connecting control and information networks increases the attack surface. Machine HMIs with USB ports that maintenance staff use to update programs are in live use in many plants. When you design Layer 4, decide the connection direction (one-way from machine upward, or bidirectional), the authentication method, and how USB ports are physically handled.
Pre-Order Checklist
Here is everything above, arranged as items to fill in before ordering. Approach vendors with this table completed and both quote accuracy and comparability change substantially.
| Layer | Item | What to fill in | Risk if left undecided |
|---|---|---|---|
| Common | Role of the screen | Is it machine operation, supervision, or public display? Division with SCADA and andon | Roles mix and screen count balloons |
| Common | Screen classes and counts | Counts for display-only / with operations / settings and masters / trends | You supply only a screen count, and quotes cannot be compared |
| Layer 1 | Screen hierarchy | How many levels; up to which level routine tasks complete | Navigation becomes ad hoc and operators get lost |
| Layer 1 | Always-visible elements | What appears in the header common to all screens | Current operating state becomes unknowable screen to screen |
| Layer 1 | Hidden in normal operation | The range of information moved to detail screens | An “everything on it” screen where abnormality is buried |
| Layer 1 | Color policy | Saturation in normal state; colors reserved for deviation | Color saturates and abnormality display stops standing out |
| Layer 2 | Alarm candidate sorting | Sort every bit into escalate / log only / do not surface | Every bit floods the list and flood becomes the normal state |
| Layer 2 | The seven rationalization fields | Tag, description, cause, consequence, action, priority, acknowledgement | Messages read like “M120 ON” and lead to no action |
| Layer 2 | Rate targets | Target rates for steady state and upset peak; priority distribution | No target, so reduction discussions stay subjective |
| Layer 3 | Languages and default | Which languages are supported; which appears at startup | Local operators cannot read it and engineers get tied to the machine |
| Layer 3 | Switching method | Button switching, login-linked, or dual labeling | A method change after implementation means rebuilding every screen |
| Layer 3 | Translation source and glossary | Who translates; how machine-specific terms are standardized | Literal translation that fails to convey the action |
| Layer 3 | Permission levels and operation matrix | How many levels; the scope of each | Everyone reverts to sharing the administrator account |
| Layer 3 | Operation logging | Required or not, retention period, retrieval method | Condition-change history cannot be traced and quality investigation stalls |
| Layer 4 | Items sent upstream | Send or not, per data type | Data lives only on the screen and cannot be analyzed later |
| Layer 4 | Connection method and interval | OPC UA / MQTT / direct DB write etc.; transmission interval | Methods vary machine to machine and cannot be consolidated later |
| Layer 4 | Behavior on link loss | How the HMI behaves when the upper system is down | The machine stops on link loss, or data is lost |
| Layer 4 | Network segmentation | Boundary between control and information networks; USB port handling | Connection is rejected later on security grounds |
| Contract | Deliverables received | Project files, design documentation, translation files | A machine nobody can modify later |
| Contract | Commissioning support scope | Attendance days, training and its language, response time, warranty period | Extra-charge negotiations and a delayed start-up |
| Contract | Acceptance criteria | Method for verifying multilingual display and alarm behavior on the actual hardware | Delivered with broken text on the real panel |
Not one item on this checklist can be decided by the vendor on your behalf. All of them are buyer decisions. Which is to say: filling in this table is touch panel screen design. Drawing is the implementation work that follows.
Frequently Asked Questions
What exactly does touch panel screen design decide?
It is not the work of drawing a layout; it is the work of deciding four layers. Layer 1, information design, decides the screen hierarchy and what is not shown during normal operation. Layer 2, alarm design, decides which of the PLC’s fault bits are escalated to a human and, for each, who does what. Layer 3, language and permissions, decides who performs which operation in which language. Layer 4, the data exit, decides whether values shown on screen stay in the HMI or go to MES or an IoT platform. All four are information only the buyer holds; a vendor cannot decide them for you. Drawing is the implementation work that comes after those four layers are settled. When quotes diverge, it is usually because one of the four arrived undecided and the vendor priced that uncertainty.
What determines the cost of HMI screen development?
Six line items, mainly. Screen count and screen type (display-only, with operations, settings and masters, or trends), the tag count exchanged with the PLC and how well address allocation is organized, the number of alarm definitions and who writes them, the number of languages and who supplies the translation, permission levels and whether audit logging is required, and whether there is upstream integration and by what method. Of these, the two you can move simply by deciding in advance are alarm definitions and translation. Leave those to the vendor and the review-and-rework round trips are priced in as hours. If you ask for a cost indication, insist that assumptions be stated — counts by screen class, alarm definition count, number of languages, and whether upstream integration is in scope. A lump sum without assumptions is useless for comparison and for budgeting.
Can PLC program development and HMI screen development be ordered separately?
Technically yes. But if you split them, you must fix the boundary as a specification: the list of shared device addresses, what each bit and word means, and which side writes and which side reads. Split without that boundary specification and, when a fault appears, both parties will claim it belongs to the other side, and isolation alone consumes the schedule. For a new machine, ordering both together preserves consistency more easily; for adding an HMI to existing equipment or refreshing screens, split ordering becomes realistic. If you do split, write the boundary specification yourself as a document and give the identical copy to both companies. Also note that adding an HMI to existing equipment involves control panel modification, so confirm the panel cutout, power supply and internal space first.
Is compliance with ISA-101 or IEC 63303 mandatory?
For delivering a single machine, there is no legal obligation to comply. There is, however, real value in referencing them. ISA-101.01-2015 and the technical reports ISA-TR101.01-2022 and ISA-TR101.02-2019 treat the HMI not as a screen deliverable but as a lifecycle of design, implementation, operation and continuous improvement, applicable to continuous, batch and discrete manufacturing alike. IEC 63303 Edition 1.0, published in August 2024, is the international standard built on ANSI/ISA-101.01; developed by WG19 under IEC TC65/SC65A, it defines the full lifecycle from concept through decommissioning, the terminology and models, and the work processes for maintaining an HMI. In practice, adopting just the thinking these standards embody — decide what is not shown in normal operation, tie alarms to human action, and assume the HMI must be maintained after delivery — is effective on its own as an internal design guideline. Reflecting those three points in your specification is more realistic than demanding clause-by-clause compliance.
What should we watch when building multilingual HMI screens at a plant in Thailand?
Five things. First, size frames against the longest language. Fix button and label frames to the source language’s character count and text overflows the moment anyone switches. Second, Thai line height: Thai script carries tone and vowel marks above and below the baseline and needs more vertical space, so line spacing tightened for a compact source language clips the marks. A missing mark changes the word, so this is meaning, not cosmetics. Third, Vietnamese diacritics, which some fonts render incorrectly — make display verification on the actual touch panel an acceptance item. Fourth, do not settle for literal translation: alarm messages must be redesigned into sentences that convey the operator action. Fifth, supply the translation and glossary yourself, because only the plant holds the vocabulary the local operators who actually run the machine use. As background, JETRO reports wage increase rates at Japanese-affiliated companies in Thailand of 3.8% in 2023, 4.58% in 2024 and a projected 4.64% in 2025, with the perceived shortage of manufacturing workers at 42.3%. Making screens that local operators can work unaided is a question of operating capability, not appearance.
Summary
Outsourcing touch panel screen design is not about pushing drawing work outside. It is about deciding which decisions stay with you and which you hand over. What moves both the cost and whether the screen is actually used on the floor is four layers: information design, meaning what is not shown in normal operation; alarm design, meaning which bits are escalated to a human and who does what; language and permissions, meaning who performs which operation in which language; and the data exit, meaning where the numbers on the screen are stored. ISA-101.01, and IEC 63303 which was published as an international standard based on it in August 2024, say the same thing — an HMI is not a screen deliverable but a lifecycle from concept through decommissioning.
For alarm design there are quantitative benchmarks you can reference. In steady state, fewer than 1 alarm per 10 minutes per operator (roughly 150 per day as a guide); fewer than 10 per 10 minutes even at an upset peak; more than 10 in 10 minutes is an alarm flood; standing alarms fewer than 10; priority distribution of high 5%, medium 15%, low 80%. Holding these as design targets alone pulls alarm definition out of the realm of opinion. And the seven rationalization fields — tag name, description, cause, consequence, operator action, priority and acknowledgement — can only be written, one alarm at a time, by the party that runs the machine.
At a plant in Thailand, Layer 3 carries more weight than it would at home. JETRO reports wage increase rates at Japanese-affiliated companies in Thailand of 3.8% in 2023, 4.58% in 2024 and a projected 4.64% in 2025, a widening increase, with the perceived shortage of manufacturing workers at 42.3%. A screen local operators cannot read comes back as a permanent draw on the hours of the one expatriate engineer who can read it, and the moment that engineer takes leave or rotates home, nobody can configure the machine. Localization and permission design are not a usability topic; they decide whether the plant can run its own equipment. The push toward higher value-added Thai manufacturing that JETRO points to likewise includes building the capability to operate automation locally, not just installing it. Together with the BOI investment promotion measures for the automation machinery and robotics industries, this is worth checking at the earliest stage of assembling an equipment specification.
Finally, one contractual item that cannot be dropped: the agreement to receive project files, design documentation and translation files. Machines run for more than ten years; the relationship with a vendor may not. Equipment installed under a contract that gives you no access to the source becomes, a few years later, equipment nobody can touch.
Whether you are at the stage of building touch panel screens for the first time, or at the stage where the screens on a running machine are simply not being used on the floor, we are happy to talk it through. Show us screenshots of the existing screens and the PLC device list, and we can give you an initial read on which of the four layers is unaddressed and where to start for the most effect. It is fine even at the exploratory stage, before you have decided whether to go as far as upstream system integration. Get in touch through our contact page.
References
- ISA-101 Standards (International Society of Automation)
- IEC 63303:2024 Edition 1.0 (IEC)
- New international standard: Human-Machine Interfaces (IEC Blog)
- ISA-101.01 Human Machine Interfaces for Process Automation Systems (InTech, ISA)
- Alarm Management Standards and Guidelines (exida)
- Alarm Management by the Numbers (Emerson)
- Alarm Rationalization Explained (Seqent)
- Wage trends and labor shortage in Thailand (JETRO regional analysis report)
- Investment promotion policy for automation and robotics industries (BOI, Thailand Board of Investment)
- Shifts in trade and investment structure and the upgrading of Thai manufacturing (JETRO regional analysis report)
