Specify a read-only process display for a plant

Define what the display may do

Write a short scope that distinguishes observation from operation. “Show local process information” leaves too much open for configuration and acceptance.

Group the requirements into three lists:

Information to show

• Process values, with engineering units and required decimal places.
• Equipment states, including the meaning of each state.
• Alarm indications, with their source and priority.
• Data quality and connection status.

Actions that are not required

• Starting or stopping equipment.
• Changing setpoints, modes or recipes.
• Acknowledging or resetting alarms.
• Editing controller values or configuration.

Operating limits

• Who uses the information and from what viewing position.
• Whether another approved interface remains available for control.
• What the display should show when information is unavailable.
• Which decisions must not depend on this display alone.

Alarm acknowledgement is an action, even when it appears beside an otherwise read-only alarm list. Include it only through a separately approved control requirement. Keep the terminal outside the plant's safety functions.

If the scope is still unclear, the distinction between a factory status display and an operator HMI helps establish the boundary before specifying hardware.

Confirm the controller connection separately from the editor

The controller's programming software and the terminal's screen editor serve different jobs. A terminal can support a controller connection while requiring a separate engineering package, runtime entitlement and application-transfer method.

Controller and data path

• Record the controller family, firmware revision and communication interface.
• Document the approved network route, including any gateway or intermediate data service.
• Identify the exact terminal driver and its documented compatibility with that arrangement.
• Check support for the tag scopes, arrays, structures and data types the proposed screen needs.
• Establish the permitted polling load with the controls team.

Engineering and recovery tools

• Identify the screen editor and versions compatible with the selected runtime.
• Confirm legitimate engineering and runtime licensing requirements.
• Obtain software and documentation from the manufacturer or its distributors.
• Confirm how an application is transferred, backed up and restored.
• Record which project files and communication settings maintenance must retain.

An Ethernet connector establishes neither protocol compatibility nor access to controller tags. A successful network reachability check is not an application test. Require the proposed driver to read representative values through the intended route.

Make read-only a data-access requirement

Removing buttons is useful, but it is not the same as preventing writes. A hidden page, script, startup action or editable object can still contain a write operation.

Application checks

• Remove numeric-entry fields, command buttons and write-capable scripts.
• Inspect startup actions and navigation to maintenance pages.
• Check alarm acknowledgement, reset and diagnostic functions for unintended writes.
• Review imported templates rather than assuming they contain only display objects.

Access checks

• Apply supported read-only permissions at the controller or intermediate data service where available.
• Use a dedicated, least-privilege connection identity where the platform supports one.
• Restrict network access to the approved communication path.
• Protect project editing and runtime configuration through the platform's documented access controls.

Network filtering is not automatically read-only enforcement. Read and write operations may use the same connection. If the selected controller interface cannot restrict writes, record that limitation and assess an approved read-only data service rather than treating an empty screen toolbar as protection.

Review this boundary through documentation, configuration inspection and a manufacturer-supported test environment. Do not attempt a write to a live process merely to prove that access is denied.

Survey the cabinet before choosing the terminal

Measure the installation rather than selecting by diagonal size alone. A display that fits the visible door area may still obstruct wiring, door movement or replacement access.

Mechanical fit

• Available door area, proposed cutout and mounting method.
• Installed depth, connector access and cable bend space.
• Door swing, nearby equipment and internal obstructions.
• Clearances and orientation required by the selected terminal's instructions.
• Access for replacement without disturbing unrelated wiring.

Environmental fit

• Splashing, cleaning spray and chemical exposure at the front.
• Humidity, condensation and contamination inside the cabinet.
• Expected temperature at the terminal location, not just room temperature.
• Protection of the rear housing, connectors and cable entries.
• Gasket, cutout and enclosure requirements for the exact mounting arrangement.

Electrical fit

• Supply compatibility with the selected terminal's documented requirements.
• Available supply capacity and the required protective arrangement.
• Grounding, bonding and cable routing specified for the installation.
• A suitable isolation method for installation and maintenance.

A protected front does not protect exposed rear connectors. Resolve the complete enclosure arrangement before modifying the door. Have qualified personnel carry out electrical and enclosure work under the site's isolation and change-control procedures.

Build a small pilot with real data requirements

Keep the pilot narrow enough to diagnose. Include representative values, not every graphic planned for the finished application.

Prepare the pilot

• Select an analog value, a discrete equipment state and an alarm indication where these are in scope.
• Include examples of any structured or unusually typed tags.
• Record the source tag, units, scaling and expected range for every object.
• Agree the required update interval and acceptable information age for each use.
• Use the intended terminal or its manufacturer-supported test environment, noting what that environment cannot prove.

Check the displayed meaning

• Compare values against an approved reference.
• Confirm whether source values already use engineering units before adding conversion.
• Check state labels against the controller's actual state definitions.
• Ensure rounding does not hide a meaningful process change.
• Review the layout from the intended position and under representative lighting.

A frequently refreshed screen can still show old source data. Specify freshness separately from screen redraw behavior. The checks in diagnosing factory screen update delay help separate those stages if the pilot exposes a lag.

Agree acceptance tests before cabinet work

Define pass conditions before the pilot begins. This prevents a readable demonstration from being mistaken for a complete installation check.

Normal operation

• Required values match the reference, including units and state meanings.
• Updates meet the agreed process-information requirement without unacceptable controller or network load.
• The application contains no unintended write functions.
• Text and status indications remain understandable at the intended viewing position.

Unavailable or uncertain data

• Use an approved test setup to check communication loss without disrupting plant control.
• Confirm that unavailable data is visibly different from a valid zero or stopped state.
• Check that a frozen value cannot appear current without a freshness or quality warning.
• Verify the intended recovery behavior after the connection returns.

Recovery and handover

• Demonstrate application restoration using the documented tools and saved project.
• Confirm how the terminal returns to its intended display after an approved restart.
• Record unresolved limitations and obtain acceptance before releasing the cabinet modification.

Do not disconnect a production control network or alter working controller logic just to exercise the terminal. Schedule any plant-dependent checks through the site's approved process.

Send a complete specification with the quote request

Provide enough detail for a model-level proposal rather than a generic screen recommendation.

Data and application package

• Read-only scope and prohibited actions.
• Controller details, communication route and representative tag list.
• Page sketch, units, update needs and freshness requirements.
• Required engineering tools, licensing and backup deliverables.

Installation package

• Cabinet drawings, photographs and measured clearances.
• Exposure, cleaning conditions and expected internal environment.
• Supply details, mounting constraints and replacement-access requirements.

Acceptance package

• Pilot test cases and pass conditions.
• Required evidence of compatibility and read-only restrictions.
• Recovery instructions and controlled project files.
• Responsibility for configuration, cabinet work and final acceptance.

Ask the proposal to identify unsupported requirements explicitly. An unresolved driver, access-control or enclosure question is a reason to hold the cabinet modification, not a detail to settle after the opening has been cut.

Questions