HMI Is More Than a Screen: Turning Machine Data into Useful Information

Start with the operating question

Consider a machine with two temperature transmitters connected to a PLC. A basic display might show Temperature A and Temperature B. That may be enough for a quick local check, but it does not explain what happened during the previous shift.

Before choosing screens or software, identify the decisions the system should support. Operators may need to recognize an abnormal condition. Maintenance may need to compare a disturbance with a machine stop. A quality reviewer may need the record for a particular production period.

Those needs overlap, but they are not identical. Writing down the intended questions helps avoid buying functions that nobody uses while overlooking information that matters.

Make the live reading understandable

Each value should have an unambiguous description, an engineering unit and an indication of whether the measurement is valid. “Temperature A — inlet — degrees Celsius” tells someone more than an unexplained tag number.

The measurement chain also matters. A 4–20 mA input must be interpreted using the transmitter's configured range. A display cannot improve the underlying sensor accuracy, and extra decimal places do not create better measurement quality.

An old reading should not silently look like a current one. Define how the display will indicate a disconnected device, invalid signal or interrupted communication. A clear unavailable state is more useful than a plausible-looking value that nobody realizes is stale.

Use trends to add context

A trend gives the live value a history. Displaying both temperatures against a common time axis can help a reviewer see whether a change affected both points or only one. That comparison is a starting point for investigation, not proof of a particular fault.

For this example, assume the proposed logging interval is one second. Treat that as a requirement to test, not an automatic setting for every application. Confirm that the measurement update rate and the full collection path support the intended record, and that faster events will not be mistaken for an absence of activity.

Give users practical time selections, such as the current shift or a custom start and end time. Agree on time-zone handling and clock synchronization. A trend is harder to interpret when the machine, server and exported report disagree about when an event occurred.

Design alarms around a response

An alarm should help someone decide what to do next. Define the condition, the intended recipient and the expected response. Consider whether a brief excursion should generate the same notification as a sustained deviation; the appropriate behavior depends on the process.

Acknowledging an alarm should not be presented as evidence that the underlying condition has been corrected. Keep the distinction between “seen,” “returned to normal” and any required follow-up clear to users.

Monitoring alarms are not a substitute for a machine's protective functions. Changes involving safety, interlocks or control behavior require a separate assessment and the appropriate authorized review. A project intended only to collect data should have that boundary written into its scope.

Plan the record, not just the export

Before promising reports, agree on what a usable record contains: measurement identity, value, unit, timestamp and data-quality information, together with any agreed production reference. Identify how a reviewer will recognize a gap rather than assuming that an empty period represents normal operation.

CSV or spreadsheet exports can be convenient for review, but the file format alone does not establish traceability or suitability for an audit. Customer and quality requirements may call for access restrictions, change history, controlled review or other measures that must be specified separately.

Likewise, placing files on a server does not mean they will remain available forever. Define retention, storage responsibility, backup and a way to demonstrate retrieval. Ask what should happen if the server or network becomes unavailable, and test that behavior before relying on the system.

Choose a platform after defining the scope

Siemens' November 2024 article on SIMATIC WinCC Unified PC discusses five selection themes: scalability, ownership cost, secure operation, extensibility and use of production data. It is a useful starting point for platform discussions, rather than a project specification. Siemens source

For a small monitoring project, compare what is actually needed now with a realistic expansion path. Check the proposed software version, licences, hardware, client access and logging arrangements against the requirements. Avoid assuming that a feature described for a product family is included in every configuration.

Remote access also needs a deliberate design. Being able to open a visualization in a browser is not a reason to expose a control system directly to the internet. Access and network arrangements should be agreed with the customer's responsible IT and OT personnel.

A practical acceptance check

Before handover, demonstrate a normal reading, a known input change, an invalid measurement, an alarm event and a communication interruption. Then retrieve a record for a specified period and check that the displayed and exported information can be interpreted consistently.

These tests turn “the screen works” into a more useful discussion about what the monitoring system actually does. The strongest result is not the busiest dashboard. It is a system that helps people understand the process and recognize the limits of the information available.

Planning a PLC/HMI monitoring upgrade? Contact AranVision at info@aranvision.ca to discuss your signals, operating questions and reporting needs.

Independent educational commentary by AranVision. Siemens and SIMATIC product names identify the referenced technology; no endorsement or partnership is implied.