OEM Temperature Controller HMI Specification: Define the Operator Experience

An OEM temperature controller HMI specification should define how a person understands and controls the equipment—not merely the screen size, brand colours, and a set of attractive mockups. Procurement needs a document that connects every screen and action to a user, an operating state, a permission, and an acceptance test.

That distinction matters because the same touchscreen can support very different products. A simple cold-room panel may need a clear overview, setpoint access, defrost status, and alarm recovery. A multi-zone machine may need role-based navigation, trends, maintenance diagnostics, and a controlled handoff to a PLC or gateway. Neither interface should be assumed from the display hardware alone.

This guide shows how to prepare a verifiable HMI input package while keeping standard functions, optional configurations, and project-evaluated customization separate.

Classify the HMI scope before drawing screens

Start by asking the supplier to classify each request.

Do not treat “touchscreen” as evidence that trends, history, user accounts, data export, remote access, or a particular language is included. List each requested behaviour. The supplier can then confirm whether it is standard, an available option, or engineering work that must be evaluated after the complete specification is reviewed.

Begin with users, tasks, and operating context

ISO 9241-210:2019 addresses human-centred design activities across the life cycle of interactive systems. ISO 9241-110:2020 provides general interaction principles and explicitly includes requirements analysts, evaluators, and buyers among its intended audiences. For an OEM project, that means the HMI brief should begin with real users and tasks rather than a supplier’s default screen library.

Define each role and what it must accomplish:

• Operator: identify current state, read the controlled value and setpoint, respond to permitted alarms, and avoid unintended changes.
• Installer or commissioner: enter application parameters, verify inputs and outputs, test interlocks, and restore a known configuration.
• Maintenance technician: diagnose sensor, output, communication, and power-related faults without bypassing protected functions.
• Supervisor or product owner: control access, review approved records where specified, and identify the installed hardware, firmware, HMI, and parameter versions.

Then document the context: viewing distance and angle, lighting, glove use, moisture or cleaning exposure, expected languages, user training, mounting height, permitted interaction time, and consequences of a wrong action. These inputs become design and test conditions. They should not be replaced by an assumption that a larger display automatically produces a usable interface.

Create a state model before a navigation map

The HMI must explain what the controller is doing now and what the user can safely do next. Build a state matrix for every condition that applies to the product.

Turn the approved state matrix into a navigation map. For every screen, record its parent, entry conditions, exit paths, persistent status area, permitted roles, timeout behaviour, and response when underlying data becomes invalid. A clickable prototype can demonstrate the flow, but the controlled state and navigation records should remain the contractual baseline.

Specify information hierarchy, not just colours

ISO 9241-112:2025 establishes ergonomic principles for the software-controlled presentation of visual, auditory, and tactile or haptic information. IEC 60073 establishes general coding principles for visual, acoustic, and tactile indications and actuators. These standards provide useful frameworks, but the applicable equipment and market requirements still need project-specific review.

For each screen, define:

• Which value, state, or required action has first visual priority.
• Units, decimal presentation, sign, range, and invalid-data indication.
• Terms that must match the manual, labels, alarm list, and protocol map.
• Which information is always visible and which requires navigation.
• How normal, warning, alarm, disabled, stale, selected, and editable states differ.
• How meaning remains understandable when colour is unavailable, poorly perceived, or affected by ambient light.
• Minimum language set, string ownership, translation review, text expansion allowance, and fallback rules.
• Date, time, time-zone, daylight-saving, and clock-synchronization rules if records are part of scope.

Do not release an icon because its meaning seems obvious to the design team. Record its intended meaning and test it with representative users. Do not use colour as the only carrier of equipment state, priority, or permission.

Treat alarms as an operating workflow

IEC 62682:2022 covers alarm systems presented through control systems and HMIs, including packaged systems, and frames alarms around notifying operators of abnormal conditions or equipment malfunctions and supporting a response. The ISA-18 series likewise treats alarm definition, design, operation, maintenance, and modification as a life cycle.

An HMI alarm requirement therefore needs more than a red banner. Build an alarm matrix containing:

1. Alarm identifier and plain-language message.
2. Source signal and trigger logic, including delay, deadband, and applicable operating states.
3. Priority or class according to the project’s alarm philosophy.
4. Operator consequence and expected response.
5. Display, audible indication, external output, and communication behaviour.
6. Acknowledgement, latching, reset, suppression, and return-to-normal rules.
7. Timestamp source, ordering, retention, and export requirements where history is in scope.
8. Test stimulus, expected result, and recovery evidence.

Separate alarms that require operator action from events, status messages, maintenance prompts, and connectivity notices. If the controller must integrate with a plant alarm system, define which device owns acknowledgement and how duplicate, delayed, or lost messages are handled.

Define permissions and high-consequence actions

Create a role-permission matrix for every editable parameter and command. It should state who can view, change, acknowledge, reset, force, calibrate, import, export, or restore it. For every consequential action, specify whether the HMI needs a confirmation step, a reason entry, a physical enable, a timeout, or another project-approved control.

Also define what happens after inactivity, power loss, failed login, interrupted write, invalid value, or communication loss. If credentials, electronic records, cybersecurity controls, or remote access are required, identify the applicable product, system, and market requirements instead of assuming that a generic PIN satisfies them.

The HMI should expose version identity and configuration status only to the degree required by the service and support plan. Any audit trail, account model, update method, or retention period must be explicitly included in the project scope.

Bind every display item to the control interface

The graphics and the control logic need one shared data contract. For every displayed or editable item, record:

• Source variable or register and responsible component.
• Data type, scaling, unit, resolution, valid range, and enumerated states.
• Read/write permission and validation location.
• Update rate, timeout, stale-data indication, and communication-loss behaviour.
• Command handshake, confirmation, rejection, retry, and duplicate-action rules.
• Default, retained, migrated, and reset behaviour across firmware changes.

The OEM temperature controller I/O specification defines the physical signals and loads; the HMI binding list must connect those signals to understandable states and actions. If an address, scaling rule, status meaning, or permission changes, apply the release discipline in the firmware change-control guide.

Release an HMI requirements package

A quotation-ready package should contain:

1. Product variants, target markets, applicable standards, and required languages.
2. User roles, representative users, tasks, environment, and training assumptions.
3. Operating-state and mode-transition model.
4. Screen inventory, navigation map, and persistent-status rules.
5. Data dictionary and HMI-to-controller binding list.
6. Parameter and role-permission matrix.
7. Alarm, event, message, and diagnostic matrix.
8. Controlled terminology, units, strings, symbols, and translation ownership.
9. Wireframes or interactive prototype linked to requirement identifiers.
10. Acceptance tests, deliverables, source-file ownership, revision rules, and approval authorities.

That package lets a supplier estimate the actual work. Display hardware, graphic design, firmware, translation, protocol integration, prototype quantity, validation, source deliverables, cost, minimum order quantity, and schedule can be confirmed only after those inputs are reviewed.

Validate tasks and failure recovery

Do not approve the HMI by reviewing screenshots in a meeting. Use production-intent hardware and software to run representative tasks with defined starting conditions and expected outcomes. Include normal operation, transitions, invalid entries, denied permissions, lost signals, interrupted communication, restart, acknowledgement, recovery, and language variants.

Record the exact controller, HMI, firmware, parameter, and protocol versions used. Link every result to a requirement and capture unresolved deviations. The custom controller prototype validation plan provides a wider framework for connecting requirements, test conditions, and objective evidence before pilot or production approval.

Beamform standard platforms and project evaluation

Beamform’s published BF-6910 / 6911 platform uses a separate touchscreen and mainboard for refrigeration temperature control. The published BF-6920 / 6921 platform is a touchscreen temperature-and-humidity controller, with humidity sensing described as an option. These are starting platforms; the exact standard screens, functions, parameters, and firmware must be confirmed for the selected model and version.

Beamform’s site describes HMI interface, display language, control logic, protocol, branding, and related OEM changes as customization areas. A buyer-specific screen hierarchy, graphics, terminology, language set, alarm workflow, access model, trend or history function, export, communication binding, and service tooling should therefore be treated as project-evaluated customization, not assumed stock functionality.

Send the requirements package through the contact page. Feasibility, deliverables, validation scope, ownership, compatibility, commercial terms, minimum order quantity, and schedule can be assessed only against the agreed specification.

Buyer handoff checklist

• Product variants, target markets, equipment standards, and HMI boundary.
• User roles, tasks, training assumptions, and operating environment.
• State diagram and sequence descriptions for every applicable mode.
• Screen list, navigation map, and persistent-status requirements.
• Parameter list with ranges, defaults, units, permissions, and confirmation rules.
• Alarm and diagnostic matrix with cause, response, acknowledgement, and recovery.
• I/O, variable, register, and command binding list.
• Languages, approved terminology, translation owner, and string-review process.
• Graphic assets, brand rules, symbols, and source-file deliverables.
• Prototype quantity, expected production quantity, acceptance tests, and approval owners.

Frequently asked questions

Is a screen mockup enough for an OEM HMI quotation?

No. It shows appearance but usually omits states, permissions, signal bindings, alarms, failure behaviour, languages, deliverables, and acceptance tests. Include the mockup inside a controlled requirements package.

Should the HMI show every available parameter?

Not automatically. Show information and controls required for each role and task. Engineering or factory parameters may need a protected service path, while irrelevant detail can obscure the current operating state.

Can colour alone identify an alarm or output state?

It should not be the only cue. Combine the project-approved colour convention with clear text, symbol, position, shape, or another distinguishable indicator, then validate it in the intended environment.

Who owns the HMI source files and translations?

The commercial agreement should state ownership, permitted use, editable source deliverables, fonts and asset licences, translation approval, repository or archive access, and responsibilities for future revisions.

When is a custom HMI ready for production?

After the parties approve the requirements baseline, exact hardware/software configuration, screen and language package, bindings, alarm logic, permissions, test evidence, open deviations, production files, and change-control rules—not after a visual design review alone.

Sources

• ISA — ISA-101 Series of Standards
• ISO 9241-210:2019 — Human-centred design for interactive systems
• ISO 9241-110:2020 — Interaction principles
• ISO 9241-112:2025 — Principles for the presentation of information
• IEC 60073:2002 — Coding principles for indicators and actuators
• IEC 62682:2022 — Management of alarm systems for the process industries
• ISA — ISA-18 Series of Standards