Pharma Engineering Insights

SCADA & HMI Design for GMP Manufacturing: Operator Actions, Trends, Recipes and Auditability

Design operator actions, process states, trends, recipes and auditability. Verify GMP HMI behaviour during normal operation and recovery.

G GuideGxP 9 min read
✓ Official sources and references ✓ Practical approach ✓ For pharmaceutical professionals
GUIDEGXP · PRACTICAL GMP INSIGHTS
Operator using a clear pharmaceutical SCADA and HMI workstation

An operator presses a valve command and sees its symbol change colour. The valve has not moved: the screen is showing the requested state, while the feedback is unavailable. This is an interface design failure with process consequences. A visually polished HMI can still mislead operators if it does not distinguish command, acceptance, execution and confirmed equipment state.

SCADA and HMI design for GMP manufacturing must support correct decisions during normal operation, disturbances and recovery. Graphics are one part of that task. The more consequential work defines process context, authority, action limits, records and evidence that operators can use the interface reliably.

Organize screens around operational decisions

Begin with tasks: prepare equipment, start an approved operation, monitor progress, diagnose a failed permissive, respond to an alarm and hand over a shift. Identify what operators need to know before acting and what confirms the result. The screen hierarchy should make those tasks possible without forcing users to remember information scattered across unrelated pages.

A site overview can show production and utility context; unit screens explain process state; equipment detail supports diagnosis and controlled intervention. Navigation should preserve orientation, including selected unit, batch, recipe and operating mode. Avoid identical-looking pages whose equipment identity changes inconspicuously. When commands can affect similar units, the target must remain unmistakable at the point of action.

[STANDARD] ISA-101.01-2015 addresses human-machine interfaces for process automation. Its scope provides a useful reference for lifecycle design. It does not prescribe one universally correct screen layout for pharmaceutical facilities. Apply relevant principles through the actual task, user and process context.

Make state and data quality visible

Differentiate measured state, commanded state and inferred state. A pump running indication may come from electrical feedback, controller status or an assumption based on a command. These meanings are not interchangeable. Define which source drives each indication and how contradictory signals are represented.

Show manual, automatic, local, remote, inhibited and maintenance conditions where they affect interpretation or authority. A value frozen after communication loss should not look like a healthy stable process. Indicate bad quality, unavailable data and stale information according to a documented convention. Use shape, text or other cues alongside colour where necessary so that meaning does not depend solely on colour perception.

Consider the entire signal path. An HMI may be connected to SCADA while SCADA has lost communication with the controller. A general “connected” icon is insufficient if it describes only the first connection. Operators need the status of the information relevant to the task, including its source and freshness when consequential.

Design commands as controlled interactions

For each command, define the authorized role, applicable state, prerequisites, confirmation and result. A command can be unavailable because a user lacks permission, equipment is in the wrong mode, or a process condition is not satisfied. Explain the reason clearly enough to support the next legitimate action; a disabled button without context encourages workarounds.

Confirmation dialogues should identify the target and consequence. Use them for assessed risks rather than adding identical confirmations to every action. Excessive routine prompts can train users to click without reading. For consequential parameter changes, present the existing and proposed values with units and applicable limits before commitment.

Separate acknowledgement of a request from confirmation that the process action occurred. If execution is delayed, rejected or interrupted, display that outcome. Prevent accidental repeated commands where they could cause repeated dosing, repeated phase execution or contradictory state transitions. Specify how an operator can cancel a pending request and how cancellation is confirmed.

Define setpoints and manual intervention explicitly

A numeric entry field needs engineering meaning: parameter identity, unit, range, resolution and source of authority. Distinguish operating limits from display range and from instrument capability. Define handling of invalid values, decimal conventions and unit conversions. The same number in two different units is a foreseeable interface hazard.

Manual mode requires a defined control strategy. Identify which automatic functions are suspended, which protective conditions remain active and who can authorize the transition. The interface should show that the process is under manual intervention and retain relevant actions and reasons where required. Returning to automatic operation must have defined transfer behaviour; it should not surprise the operator with an unexplained output change.

[QRM] Derive limits, confirmations and authorization from the process assessment. Neither GMP nor a generic HMI standard supplies a universal setpoint range or a universal requirement for a second person on every change. Where a second authorization is needed, design and verify its actual workflow.

Keep recipe identity connected to execution

Show the approved recipe identity and version used for the current operation. Distinguish parameters selected for the next batch from values executing now. If operators can adjust parameters within approved bounds, define how adjustments are authorized, recorded and presented during review. An editable screen should not silently overwrite the master recipe.

For procedural execution, display the current phase, relevant completion criteria and the reason for a hold. Operators need to understand what has happened and what will happen next. A progress bar cannot replace meaningful state information. Define whether repeated phase execution is permitted and what additional controls or review are required.

Include restart scenarios in interface design. After a server restart, the display must obtain the actual execution state and avoid presenting cached values as current. A recovered session should not replay an old command merely because it was pending before interruption. Controller and supervisory behaviour must agree on that contract.

Use trends to answer specific questions

Choose trend groups around operational relationships. For example, a temperature deviation may require temperature, setpoint, heating demand, valve state and phase context on compatible time axes. Make units, ranges and time windows clear. Automatic scaling can hide the practical magnitude of a change if operators cannot see how the scale moved.

Distinguish real-time display from historical retrieval. Explain data gaps, quality changes and interpolated lines where they affect interpretation. A visually continuous line can conceal a collection outage. The displayed resolution and aggregation should be suitable for the question; a summary view may be useful for navigation but inadequate for investigating a short event.

[GEP] Verify trends against known test events and retained source data. Demonstrate correct time alignment between variables, event markers and batch context. Select acquisition and display settings through intended use; there is no universal historian sampling rate or trend duration suitable for every pharmaceutical process.

Connect alarms to an actionable response

An alarm should direct attention to a condition requiring timely operator response under the site's alarm philosophy. Events, routine status changes and informational messages should not automatically compete for that attention. Present the equipment, condition, priority and relevant response context without making operators decode cryptic identifiers.

Acknowledgement confirms that an alarm has been recognized; it does not prove that the condition has cleared or that the corrective action succeeded. Keep these states distinct. Similarly, shelving, suppression and inhibition have different purposes and governance. The interface should make relevant unavailable or suppressed alarm functions visible to authorized users.

The alarm management article addresses rationalisation, delays and lifecycle controls. In HMI design, verify that the presentation supports the defined response during a realistic disturbance, including multiple related alarms. Avoid solving nuisance alarms merely by hiding them from the main screen.

Build auditability into the action path

Identify which operator actions and configuration changes require retained evidence. Depending on the intended use and applicable requirements, useful context can include user identity, affected object, previous and new values, time, reason and associated batch. An action log and a GMP audit trail may overlap, but their scope and protection need explicit definition.

Use unique accountability where required and control shared or service accounts according to their purpose. Consider shift handover, session changes, maintenance access and unattended stations. Derive session behaviour from risk and operational needs; an abrupt logout during a critical task can itself create difficulty if the recovery workflow is poorly designed.

Time information must remain interpretable across systems. Specify time synchronization, time-zone presentation and handling of clock changes. Where daylight-saving transitions occur, ambiguous local timestamps can confuse reconstruction unless the retained record preserves sufficient context. Test how screens, historical data and action records present the same event.

Translate the design into acceptance evidence

ScenarioExpected operator understandingAcceptance evidence
Valve command rejected by a permissiveRequest failed and the blocking condition is identifiableObserved task, controller result and displayed explanation
Measurement communication lostValue is unavailable or stale, not a healthy current readingInjected loss, visible quality state and retained event context
Authorized recipe adjustmentCorrect target, units, limits and version are evidentBefore/after values, authorization and traceable action record
HMI restart during an active phaseActual execution state is recovered without command replayControlled restart and comparison with controller state
Historical investigationTime, gaps and batch context can be interpreted correctlyKnown event reconstructed from trends and source records

Record the configuration and software versions tested. Keep failed observations and their disposition, including usability findings that do not produce a software error. A screenshot proves appearance at one moment; it does not establish the behaviour of an interactive sequence.

Worked example: CIP hold and manual recovery

In an illustrative CIP application, a phase holds when its defined process condition is not achieved. The initial interface shows only a red vessel and a general fault message. Operators cannot tell whether the phase has paused, aborted or continued counting time. This uncertainty creates a risk of inappropriate restart and misleading cycle interpretation.

The revised design shows the phase state, the unmet condition, the relevant trend and the permitted recovery actions. It distinguishes acknowledging the alarm from authorizing a controlled intervention. Any permitted parameter change follows the approved role and range rules, while the retained record connects the change to the cycle.

The acceptance exercise includes a process simulation, loss of one relevant signal and recovery after an HMI restart. Operators must identify the condition, select the allowed response and explain the resulting cycle state. Process specialists assess the recovery strategy; quality representatives assess the evidence needed for review. The interface cannot compensate for an undefined cleaning-process acceptance strategy.

Verify language and display conditions

Where operators use different languages, maintain consistent equipment identifiers while translating instructions and explanations deliberately. Test longer labels, decimal separators, date formats and units in each supported language. A translated alarm that loses its action meaning is an operational defect, even if the screen remains visually tidy. Avoid mixing translated terms with unexplained abbreviations.

Evaluate the actual workstation conditions: viewing distance, lighting, touch targets, gloves where relevant, and the amount of information visible without scrolling. A design reviewed on a large engineering monitor may be unsuitable for the installed panel. Record those conditions in acceptance evidence so that later hardware substitutions can be assessed against the same intended use.

Keep the interface controlled throughout its lifecycle

Manage screen objects, faceplates, scripts and configuration as controlled application components. A shared symbol change can affect many units, while a seemingly cosmetic change can alter emphasis or hide information. Assess changes against tasks and risks, and verify the affected behaviour after deployment.

[GUIDEGXP RECOMMENDATION] Maintain a concise HMI philosophy with approved conventions and representative examples. Review operational feedback, recurring navigation problems, mistaken commands and workaround practices. These observations can reveal design weaknesses that initial testing did not expose. Update training when behaviour changes, not just when a new screen is added.

  • Equipment and batch identity remain clear at action points.
  • Commands, feedback and data quality are distinguishable.
  • Manual and degraded modes have defined operational behaviour.
  • Recipes and adjustments remain traceable to execution.
  • Trend and action records support investigation.
  • Representative operators can complete abnormal tasks reliably.

Apply these principles with the process-specific work in Cleaning, CIP & SIP Systems and Cleanrooms & HVAC Systems. Return to the Automation & Digital Systems hub for architecture, integration and lifecycle decisions.

Regulatory context and primary references

[REGULATORY REQUIREMENT] Applicable GMP computerized-system and documentation controls frame the required functionality and evidence. They do not prescribe one graphical style. Reviewed 23 September 2026: operative EU GMP Annex 11 and Chapter 4 remained the 2011 texts; the 2025 revision proposals remained consultation drafts. See EudraLex Volume 4 and 21 CFR Part 11 for the applicable record framework. [STANDARD] Consult the ISA catalogue for ISA-101 and ISA-18.2. The scenarios and table above are original GuideGxP engineering guidance.

THE PRAGMATIC GMP · EVERY MONDAY

The GMP topics that matter, in 7 minutes.

One GMP topic, one real-world example and one practical action, based on official sources and inspection trends.
Discover The Pragmatic GMP