What is an HMI? Human-Machine Interfaces, Web HMI and IT Integration

An HMI consists of a display, operator input and an interface. For IT integration, the interface is what counts.

The display shows values, states and alarms, typically as a mix of process graphics, numeric fields and trend charts. Input happens through touch, keys or both. The interface connects the panel to the controller: over RS-232 or RS-485 serial links on older panels, mostly over Ethernet on newer ones.

For IT integration, what matters most is whether the panel is on the network itself or only talks to the controller. In the second case, the path into IT runs through the controller behind it. That is often the cleaner design: the controller holds the state anyway, and the panel is just a view of it. An integration that taps the panel instead depends on a display device that gets swapped out in the next retrofit, and so on the shortest-lived component in the plant.

An HMI operates one machine or one area; a SCADA system brings many of them together. The HMI on the extruder shows the extruder; the SCADA system shows every extruder with its alarms and history and sets their values side by side. An HMI can be part of a SCADA system. What separates the two is scope: an interface that operates one machine is an HMI; one that supervises a group of machines is SCADA.

For integration, this means that history and comparison across several machines live in SCADA, not on the panel. Values for analysis therefore come from the controller or from SCADA and rarely from the HMI itself, for the same reason as with tapping the panel above.

The full comparison is in the article What is SCADA?

The HMI sits at the supervisory level of the automation pyramid, together with SCADA. Below it are the controllers, above it the MES. ISA-95 does not include the HMI at all.

This model describes responsibilities; it no longer describes data paths. An ERP system can therefore exchange data directly with this level when the values are already collected there and prepared for people.

More on this: What is ISA-95?

An HMI whose interface runs in a browser instead of on a panel mounted at the machine. That changes access, updates and availability.

Access is no longer tied to a location. With the right permissions, the machine can be viewed from the office, from a tablet or while on call. That is the benefit, and it makes security a prerequisite.

Updates become central. A panel is updated on site; a web interface is updated once, on the server. Across twenty machines, that is a different amount of work.

Availability shifts. A local panel works as long as the machine runs. A web HMI also needs the network and the server behind it. That is why it makes sense to keep a local operator level even when a web interface exists alongside it. The web HMI then does not replace the panel; the two split the work. Intervening in the machine stays on the panel, because it has to work even when the network is down. Monitoring, comparing and analyzing move to the web, where more people can reach them without walking out to the shop floor. Processes can be started from both.

For the web interface alongside the panel, there are cloud-based web HMIs. The cloud platform manubes, for example, offers graphical process visualization: machines, stations or material flows as dynamic graphics that show states in real time from live production data, with mobile access to the visualizations. Buttons in a process graphic can be linked to workflow automations and then start a workflow from the graphic.

In practice: According to a STIHL case study first published in German in 2019, each assembly line had its own local SQL Server database, and central databases above them combined the information from all lines. Parts, bills of materials and production periods were provided locally long before an order started. “This means that in the event of a connection failure, the current order and the follow-up order can still be produced,” said Dominik Feil, who was then in charge of production on the IT side at STIHL. The case study names 16 installations in Germany, plus more in the plants in the USA and China. Behind it is the same reasoning as with the local operator level, one layer up: the data a line needs during a connection failure is kept at the line.

An operator presses a button on the panel, say Complete order. The button sets a value in the controller. An external system reads the controller cyclically, at a configured read interval. This is where the problem arises: a short button press can disappear completely between two read cycles.

The solution is a handshake with a response bit. When the button is pressed, the controller sets a trigger bit that stays set. The reading system detects it, fetches the associated values and then sets a response bit. Only when the controller sees that response bit does it reset the trigger and release the button again.

The operation is then acknowledged. If the response bit never comes, the controller can detect that, provided it watches for the response with a timeout of its own. It can then show the failure instead of losing it silently. Without that return path, a missing confirmation can go unnoticed until the numbers fail to add up at month-end.

A case where the manual input disappears altogether: A long-established manufacturer of specialty chemicals renewed its filling line. Before, an employee reported the number of packs back to the system by hand, applied the pallet label and then typed in the transport order. The case study on opc-router.com notes that typing and input errors often occurred during manual entry. According to the case study, the OPC Router took over when the new line was commissioned on May 1, 2019: it continuously requested data from the connected systems and, on receiving a telegram, read the number of packs and the process order number from the Siemens PLC and booked them into SAP via Remote Function Call, where the label was created and applied by machine. At the end of the process, the OPC Router returned the complete message to the PLC. Instead of entering data by hand, an employee now controlled the machine’s work steps from a terminal, the case study says. That leaves no button press that could be lost. If the telegram that triggers the booking is read cyclically, the question of acknowledgment still remains; it moves from the operator to the controller.

When a connection buffers values and delivers them later, they arrive late. For a database, that is correct: the value from earlier belongs in the history, even if it is only written now.

For a display of the current state, it is wrong. A process graphic is meant to show the state right now. A value delivered twenty minutes late is a false reading there, and unless the screen shows a timestamp, nobody can tell how old it is.

For engineering, that means: values that show a current state are not buffered, so that they are not delivered late after a disruption. Events and counts that belong in a history are buffered and backfilled. A trend chart on the panel counts as history, not as state.

Whether a value belongs to the current state or to the history has to be settled as early as the engineering phase.

On the plant side. No software decides on its own that “this value goes on a screen, that one goes into a history.” In the OPC Router, the buffer is set per flow. If current-state values and history values run in the same flow, they cannot be separated when buffering. The separation therefore comes from how the flows are cut: separate flows for separate kinds of recipients. The default also needs checking, because there is an option that turns buffering on automatically for newly created flows. Wherever values are buffered, each record should carry a timestamp: backfilled and current values do not necessarily arrive in their original order, because the catch-up transmission runs in parallel with live operation.

In the OPC Router. The OPC Router manual’s section on when Store and Forward should not be used gives as the first reason the case where only the current value counts, with a measured value on a visualization and an OPC tag as examples. The feature works at two levels and has to be enabled both globally and per flow. Per flow, there are several ways to do that: manually in the flow settings or through the flow’s context menu, through the default for newly created flows, or through a template, whose setting then applies to every flow created from it. For a flow with current-state values, this is the setting to check. Under “Tools > Settings”, the global options also include the retention time in hours, the storage capacity in gigabytes and the behavior when capacity is reached: either the flow goes into an error state, or further data is ignored.

The buffer’s limits: Once the retention time has passed, values that are too old are discarded; when the storage limit is reached, the configured behavior applies; and a transmission that keeps failing is not attempted again after a few tries. Proof that a single value arrived therefore needs a mechanism of its own; the buffer does not provide it.

Yes. An HMI or SCADA system can act as a client and call a function in middleware. An operator presses Print label or Close batch, and that starts an entire process rather than a single write to the controller: fetch data from the ERP, create the document, drive the printer, report the result back.

The difference from plain data exchange is who takes the initiative. IT does not keep polling the equipment to ask whether something happened; the operator level speaks up when something has happened. For actions a person initiates, that is the natural way. It saves the detour through flag bits and polling loops, and the parameters passed with the call are available in the flow: they can be processed further and logged deliberately, instead of someone having to interpret a bit change after the fact.

In practice: At HERMA, the maker of self-adhesive materials, a technical co-worker issued a transport order directly at the roll cutting machine. Via the OPC Router, the system then notified a transport vehicle that took the roll to the central packaging station. Packaging, palletizing and shrink-wrapping ran there from the order data sent along, and the integrated scale sent the weight to SAP, which generated the loading papers and customs documents. The case study on opc-router.com, whose company details refer to the 2017 financial year, names 14 machines and 35 PLC systems linked to SAP through the OPC Router, and around 15,000 telegrams a day. The SAP communication was safeguarded by Remote Function Calls with a handshake, on the same principle as the response bit above.

An operator prints a label, the panel reports an error, and the label comes out of the printer anyway. Cases like this arise at the boundary between what a person sees on the panel and what happens in the system. There is no shared safeguard at that boundary, so the following problems are built into the way the integration works.

The operator sees an error, and the action ran anyway

A panel triggers an action, a label print for example. The call’s timeout expires before the flow is done. The panel reports a failure while the flow keeps running and does what it should. The label gets printed.

The cause: There is no transaction wrapping the call and the flow, just two independent time limits. One limits how long the caller waits, the other how long the flow may run. A timeout on the panel therefore says nothing about whether the action took place, and by design it cannot.

The symptom: Duplicate labels, duplicate bookings, duplicate quantity reports after a disruption, because someone pressed the button again after seeing the error.

On the plant side. The time limits have to be aligned with each other during engineering. In the OPC Router, these are two separate values: the wait time of the calling client in the trigger dialog, and the flow timeout in the flow settings (also called the connection timeout in the manual), which defaults to 300 seconds if nothing else is set. For the operator to see the real result, the wait time has to cover the longest expected run time of the flow. The panel logic must not draw conclusions about the outcome from a timeout. Whether the screen then locks the button, asks the operator or reads the state back from a result data point is defined in the HMI project and nowhere else. The operation also needs a business key (order number, batch number, counter value) that the target system checks before writing. The OPC Router does not reverse a flow that has already run.

In the OPC Router. It can expose the operator action as an OPC UA method that the HMI or SCADA system calls as an OPC UA client. The call is synchronous, and the status code of the response is derived from the transfer result: success becomes Good, an abort becomes Bad_OperationAbandoned, an error becomes Bad with the abort text. In the normal case, the panel can therefore see the real result rather than just an expired wait. This is configured in the dialog of the OPC Method Trigger. Its Timeout field only limits how long the caller waits; it does not stop the transfer. Only the flow timeout ends a running transfer.

The manual describes the limit: the two time limits are independent, and there is no wrapper that turns call and flow into a single transaction. The OPC Router makes the limits named and configurable; aligning them is up to the engineering.

Turning an open outcome into a defined one. A failure can be contained. The Error Handling (Try/Catch) transfer object places part of a flow in a TRY branch and exposes the result as a status you can evaluate: Succeeded as a Boolean, AttemptCount as the number of attempts, Recovered for a handled error and LastErrorMessage for the error text of the last attempt. These outputs can be wired to another transfer object in the same flow and written back to the controller or the panel. The CATCH branch can also send a notification, an email to the shift supervisor for example. That turns “something went wrong” into a sentence the HMI can display.

Automatic retry: It is disabled by default. It re-executes the entire TRY branch, including the steps that had already succeeded. Enabled for a flow that must not run more than once, it produces the duplicate booking described above as a symptom. Up to 4 retries can be set, 3 by default, with a wait time of 1 second by default; a branch call has a time limit of 30 seconds, and anything that runs longer counts as a failed attempt. And without a CATCH branch, a final failure is swallowed: the transfer stays green. For subsequent steps to react, the status outputs have to be evaluated, for example Succeeded = false and the error text in LastErrorMessage.

Pressed twice does not mean transferred twice

The handshake with a response bit has a gap of its own. If the trigger bit changes twice within one read cycle, the reader misses the second change. The transfer does not happen, and neither does the response bit. This is the case with a quick second button press, shown in the lower half of the diagram above.

The cause: Between controller and reading system, values are sampled, not pushed as notifications. The connection reports the state at the moment of reading, not a sequence of edges. Whatever happens between two cycles does not exist for the reader, because nothing records it. No recipient can recover the lost press, not even after the fact.

How large that window is depends on the configured read interval. The OPC Router manual gives no recommended value: the interval is configurable, “0” stands for the server’s fastest possible rate, and in one of the manual’s performance tests it is set to 1,000 milliseconds, in another to 250. An operator can press a button twice in well under a second, and a controller that sets a bit and clears it in the next cycle can do so even faster as soon as its cycle is shorter than the read interval: the bit can then fall entirely between two read points.

That is why the timeout from the handshake above is mandatory: the only place where the missing response can be noticed is the side that started the operation. With a lost second press, there is no acknowledgment to see. All anyone can notice is that it never arrives, and even that only if the controller tracks the response bit with its own timer that escalates after the deadline instead of waiting indefinitely.

On the plant side. The OPC Router manual explicitly assigns three duties in the PLC program to the controller. A timeout on the response bit that restarts the send after a defined interval and, after several unsuccessful retries, treats the condition as an error, that is, reports or escalates it. Write the handshake bit from one side only: the controller resets the trigger data point itself after it has received the response. And write the trigger last: first all related values, then the bit.

In the OPC Router. The handshake itself is available as ready-made configuration. The Bit trigger fires as soon as the trigger data point takes on a value other than 0. Several settings are configured together: “Reset bit” stays disabled, because a handshake bit should be written by one side only; “Response bit active” is enabled and given a logical bit data point; “Reset response bit after” sets the interval after which the OPC Router resets that bit to 0 itself. An error bit that is set on a failed transfer can be added. For a trigger bit that stays set, there is also “Wait for falling edge”: when enabled, the trigger fires once and considers the bit again only after it changes from 1 to 0, instead of firing again on every read cycle. Without anything to configure, the OPC Router waits one additional read cycle after the trigger fires, so the controller has time to write all related values. The read interval itself is the Sample Rate on the “Advanced” tab of the OPC UA connection.

The second proven form is the Message trigger, a counter instead of a bit. Instead of setting a bit, the controller increments a counter by 1 for every new record, and the Message trigger fires on every change of that numeric data point. Each operation is then numbered rather than simply set or not set. The response data point can be a counter as well, so the controller compares message ID and response ID instead of waiting for a bit. There is also a field the Bit trigger does not have. “Trigger on startup” offers the option only when the message and response IDs differ: after a restart, the trigger then fires if the last response is still missing.

What a counter cannot do either. It makes loss detectable, not impossible. If the counter jumps by 2 between two read points, from 5 to 7 for example, only one transfer takes place. That is the sending side’s mistake: the controller wrote the next record before the response to the previous one arrived. The gap is visible in the counter value; with a bit, it would leave no trace. If the counter value is logged, as the manual recommends, you can trace whether records were skipped or transferred twice. That evaluation happens outside the middleware. Avoiding the gap is the controller’s job: it writes the next record only after the response, and the timeout on the response counter stays in the controller as well.

After a connection loss, the active alarms are missing

A system that subscribes to alarms in order to forward them only sees new state changes after it reconnects. Alarms that are already active and unacknowledged do not show up.

The cause: A subscription is a stream of changes, not a state query. A standing alarm generates no event because nothing changes, and the stream has no past: it starts the moment you subscribe. OPC UA provides a separate call for this case, which delivers the current set once. Where that call is not made, the overview shows only state changes by design, not the current set.

The symptom: After a restart, the alarm overview is empty while red messages are showing on the panel. An alarm appears in the forwarding only when it is acknowledged, which is backwards.

On the plant side. Here the burden lies almost entirely with the plant owner, because the gap follows from how subscriptions work. An alarm forwarding path must not be the only source as long as the current set is not reconciled. Reconciliation has to be engineered, either through a method call whose behavior is tested in the specific project beforehand, or by cyclically reading state data points the controller keeps anyway, that is, through values instead of events. What the plant’s OPC UA server offers matters too: which nodes provide which events is documented by that server, not by the middleware.

In the OPC Router. It includes an Alarm/Event trigger that responds to events from an OPC UA server. Each state change is a separate event and triggers a transfer, including acknowledgment and confirmation; the middleware itself acknowledges nothing. Delivering the current set, by contrast, is not a property of a subscription. The separate call OPC UA provides for it has to be triggered; it does not happen on its own. For alarm forwarding, the project therefore has to settle how the current set is reconciled after a restart, and check whether the OPC UA server in use offers that call. Building blocks that could trigger such a reconciliation exist: a transfer object for OPC method calls, and triggers that fire on a schedule. A test in the project shows whether they hold up in a given case.