Why Pharmaceutical IoT Compliance Needs Read-Only PLCs

OPC-UA and MQTT collect audit-ready energy data while leaving validated PLCs unchanged.

EU GMP Annex 11 requires pharmaceutical manufacturers to validate computerised applications, qualify supporting IT infrastructure and apply documented risk management throughout the system lifecycle. An Industrial IoT connection to a production PLC therefore needs a defined compliance boundary before it collects its first energy or utility value.

Pharmaceutical sites need better visibility of electricity, steam, chilled water, compressed air, HVAC operation and water systems. These signals can support facilities investigations and production-linked energy analysis. They may also sit alongside validated equipment controlling cleanrooms, sterilisation, water treatment, filling or packaging.

Industrial IoT compliance in pharmaceutical manufacturing depends on protecting that divide. Read-only PLC connectivity collects approved signals without giving a monitoring platform the ability to alter the manufacturing control layer. It narrows the interface function, supports proportionate validation and gives Quality Assurance clearer records to inspect.

Read-only PLCs define the system boundary

A read-only PLC connection allows a collector to retrieve an agreed set of values from a PLC, meter, historian or building management system. It has no authorised function to change the source system.

For a GMP-regulated site, that constraint must be more than a statement in a project brief. The design should make the permitted function visible in access arrangements, interface configuration, test evidence and operating procedures.

What a read-only connection excludes

The monitoring environment should have no capability to:

• Change process setpoints, recipes or alarm limits
• Start, stop, reset or acknowledge equipment
• Write values into PLC registers, tags or variables
• Change PLC logic, firmware or user permissions
• Create or amend manufacturing records at the source

This is particularly relevant where a PLC controls GMP-relevant equipment. A utility monitoring platform may retrieve a fan-running status, electrical load, steam totaliser, temperature trend or approved batch-state signal. It has no control authority over the air-handling unit, water-generation skid, autoclave, bioreactor or packaging line.

This functional boundary reduces the routes by which a monitoring integration could affect process control or product quality.

Intended use determines GMP impact

The presence of a utility value does not automatically make an energy platform GMP-critical. Its intended use determines the assessment.

A system used solely for facilities consumption review has a different impact profile from one whose records inform a deviation investigation, support a product-quality decision or provide evidence for batch release. Quality teams should establish that distinction before configuration begins.

The GMP impact assessment should answer specific questions:

1. Which source systems and signals are in scope?
2. Is each signal directly GMP-relevant, indirectly useful during investigations, or facilities-only information?
3. Does the system copy, transform, aggregate or time-align the received value?
4. Can an outage affect manufacturing, or does it only remove visibility?
5. Who can configure, view, export, administer and review the data?
6. Which records require retention, retrieval and periodic review?

This assessment prevents two familiar errors: treating a facilities tool as exempt from GMP scrutiny despite its use in investigations, or applying the full burden of a batch-control system to utility data with no role in product decisions.

Annex 11 makes interface design a validation matter

The European Commission’s EU GMP Annex 11, Computerised Systems, applies to computerised systems used in GMP-regulated activities. It requires a justified, documented risk assessment based on patient safety, product quality and data integrity.

The boundary created by read-only PLC connectivity supports that assessment. It shows that the integration collects data from a defined source but cannot send commands into the validated control environment.

Validation must cover the actual lifecycle

Annex 11 requires lifecycle validation documentation and reports. Manufacturers must justify their standards, protocols, acceptance criteria, procedures and records through the risk assessment.

For an Industrial IoT deployment, the validation record should establish the journey from source value to displayed or exported information.

An interface specification can identify:

• Source equipment and approved signal identifier
• Signal description and engineering unit
• Expected range, resolution and collection frequency
• Timestamp source, time-zone treatment and clock-synchronisation responsibilities
• Scaling, unit-conversion and aggregation rules
• Data-quality status for unavailable, delayed, duplicate or implausible values
• Destination data store, retention period and export controls
• Responsibilities for reviewing alarms, exceptions and configuration changes

An electricity meter may provide a cumulative kWh total while the monitoring application calculates interval consumption from successive readings. That calculation can support energy analysis, but it changes how the information is interpreted. The specification and functional testing should show how the platform handles a meter reset, an unavailable reading, a late record or a timestamp discrepancy.

Data transfers need controlled meaning, not merely connectivity

Annex 11 requires appropriate checks for the correct and secure entry and processing of electronically exchanged data. It also requires validation to confirm that transferred data have not changed in value or meaning.

That requirement matters in pharmaceutical IoT integration. A value can retain the same number while losing meaning through an incorrect unit, an undocumented scaling factor, a missing timestamp or a mismatched asset name.

A sound design preserves source provenance. Each monitored point needs a stable source reference, documented unit and clear relationship to the physical asset. A steam totaliser should not appear as a generic “steam use” trend without a record of meter identity, accumulation basis and location in the utility system.

Where a platform receives batch information or equipment state as context, the data model should state that the value is a copied contextual signal. The monitoring application must not become the authoritative source for batch identity, batch status or manufacturing history.

Data integrity extends beyond the PLC value

Read-only access protects the source controller from unauthorised changes by the monitoring platform. It does not protect the copied data, calculations, configuration or reports that follow.

The data lifecycle requires controls at each stage: collection, processing, storage, review, export, retention and retrieval. UK pharmaceutical manufacturers can also draw on MHRA guidance on GxP data integrity, which addresses data governance across the pharmaceutical lifecycle.

Source data and derived records need different controls

The source PLC or meter record and the monitoring platform’s derived information are related but distinct. Quality and engineering teams should define which is authoritative for each purpose.

For example:

A reported value should remain traceable to its source signal and collection time. If a platform creates a KPI from several utility readings, the calculation logic, asset mapping and time window need version control. Otherwise, an engineer cannot explain why an investigation report changed after a configuration amendment.

Audit trails must cover GMP-relevant configuration actions

Annex 11 calls for risk-based consideration of system-generated audit trails for GMP-relevant changes and deletions. It requires documented reasons for changes or deletions of GMP-relevant data, intelligible audit trails and regular review.

A monitoring platform’s audit trail should cover actions within its own boundary, including:

• Addition, removal or remapping of a monitored signal
• Changes to scaling, unit conversion or KPI calculation
• Changes to a data-quality rule or exception treatment
• Changes to batch-context mapping
• User-account, role or permission amendments
• Configuration releases, software updates and report-template changes
• Correction, exclusion or deletion of GMP-relevant records

The audit history should identify the person, date and time, previous and new configuration values, and the approved reason where required. A platform event log is not automatically an audit trail. The site must establish whether the record captures the relevant user action and whether reviewers can interpret it.

Availability must not become false certainty

A utility platform will occasionally lose contact with a source system. The compliant response is to show the data condition, preserve the exception and follow the defined recovery process.

It is unsafe to present substituted or stale values as current readings without clear status. The system specification should define what the platform displays after communication loss, how it records the gap, whether it buffers data, and how it identifies recovered records. If manual correction is permitted, the process requires controlled authority, reason capture and an auditable record.

GAMP 5 supports proportionate validation effort

ISPE’s GAMP 5 Guide, Second Edition, sets out a risk-based approach to compliant GxP computerised systems. Its focus is fitness for intended use, patient safety, product quality and data integrity.

This approach suits utility-monitoring integrations because it directs verification towards credible failure modes rather than a generic checklist.

Read-only operation reduces functional scope

A monitoring system configured without a write function has a smaller functional scope than a two-way process interface. It cannot issue a run command, adjust an alarm threshold or replace a process value.

The risk assessment can therefore concentrate on the remaining risks:

• Incorrect source selection or asset mapping
• Loss, duplication or delay of collected data
• Incorrect scaling, unit conversion or aggregation
• Unauthorised configuration changes
• Inappropriate user access or report export
• Failure to identify an unavailable or unreliable value
• Loss of retrieval capability for retained records

This does not make a read-only connection automatically compliant. It provides a defensible basis for proportionate requirements and test coverage.

Acceptance criteria should be observable

A pharmaceutical site should be able to test the requirements that define the boundary. Broad claims such as “secure”, “validated” or “non-invasive” do not provide acceptance criteria.

Useful test evidence confirms that the collector accesses only an approved data-point list; that each displayed value matches the agreed source, unit and timestamp treatment; and that the specified account cannot perform prohibited control actions.

Testing should also cover failure scenarios. A team can interrupt source communications, make a permitted configuration change, attempt an unauthorised privilege change and restore service. The resulting records should show system behaviour, audit entries, alert status and recovery outcome.

A validation package for the integration commonly includes the following evidence.

Governance keeps a read-only design valid after commissioning

Annex 11 requires controlled change and periodic evaluation. The latter should consider functionality, incidents, upgrades, performance, reliability, security and validation status.

Read-only PLC connectivity is a condition to maintain, not a one-time commissioning result.

Ownership needs to be explicit

Quality Assurance, automation engineering, facilities, OT or IT security and the system owner should agree responsibilities before deployment. The operating model should identify who approves signal additions, who reviews audit records, who owns source-system changes and who assesses supplier updates.

A source PLC change can affect a monitoring interface even when the monitoring system has not changed. A renamed tag, revised scaling factor, replaced meter or altered timestamp setting may invalidate part of the approved data-point specification. Change control should trigger an impact assessment and proportionate re-verification.

Periodic review should test the boundary in service

Periodic review should confirm that the production configuration still matches the approved design. It can include active data points, privileged accounts, configuration releases, communication incidents, data exceptions and unresolved deviations.

The review should also confirm that the monitoring system remains within its intended use. If a facilities dashboard begins to support formal GMP investigations or quality decisions, the site must reassess data-integrity controls, validation scope, record retention and review requirements.

Omni Vision acceptance criteria for pharmaceutical sites

For an Omni Vision pharmaceutical deployment, the site should define a controlled list of utility and contextual signals before installation. The system record should identify each electricity, gas, water, steam, compressed-air or oil measurement in scope, with meter identity, unit, collection interval and intended reporting use.

The commissioning package should establish that the deployment collects data from approved sources and has no authorised control function over the originating PLCs or validated manufacturing equipment. It should also demonstrate that authorised users can retrieve required records, identify unavailable data, review relevant configuration changes and assess the effect of platform or source-system changes.

This evidence gives Quality Assurance a basis to approve the integration and operations a record for investigating utility performance.

---

This article reflects the independent analysis and editorial opinion of EnerTherm Engineering. Product names, trademarks, and brands mentioned belong to their respective owners. EnerTherm Engineering is not affiliated with, endorsed by, or a licensee of any third-party software or product mentioned unless explicitly stated.