A production message reaches MES, the network dashboard is green, and the interface team reports success. The receiving application has rejected the material identifier, however, so no manufacturing transaction exists. A successful network connection is not a successful GMP transaction. Integration must establish meaning, acceptance, persistence and reconciliation across the complete path.
This article addresses interfaces between PLC, SCADA, historian, MES, LIMS, ERP and warehouse systems. The objective is a controlled exchange that remains understandable during normal operation, errors and recovery. Protocol selection matters, but it follows the definition of the manufacturing transaction.
Start with the event and its business meaning
Describe what causes an exchange: an order is released, material is issued, a phase completes, a sample is registered or a result is approved. Define the state before and after the event in both systems. Avoid vague interface requirements such as “send batch data” that leave timing, content and acceptance undefined.
Identify the authoritative owner of every exchanged object. ERP may own a business order while MES owns its execution state; LIMS may own approved laboratory results while MES consumes them for a defined decision. A warehouse system may manage stock movements without owning the manufacturing meaning of consumption. Actual allocations depend on the site's architecture.
[STANDARD] ISA-95 provides useful terminology and models for enterprise-control integration. It does not remove the need for a site-specific transaction contract. Map responsibilities and states explicitly, especially where different applications use the same term for different events.
Create an interface contract that both owners can test
The contract should define the trigger, sender, receiver, payload, identifiers, units, permitted values and validation rules. Specify mandatory and optional fields, supported versions and handling of unknown fields. Include the expected response and the point at which responsibility transfers. An interface diagram without these rules is insufficient for acceptance.
Define the transaction identity independently of transport sessions. A retry after reconnection must be recognizable as the same intended transaction where appropriate. Retain correlation information so that support teams can follow an exchange across middleware and application logs without relying on coincident timestamps alone.
Document error categories and their owners. A temporary communication failure, an invalid master-data reference and a prohibited process state require different responses. Do not retry every rejection indefinitely. Some errors require correction and authorized resubmission, while others should remain quarantined for investigation.
Select technology against the exchange requirements
OPC UA can support industrial information exchange with defined information models and security capabilities. APIs can support application transactions, while messaging services can decouple systems and buffer exchanges. File transfer or database interfaces may remain necessary for legacy equipment. None is inherently sufficient for a GMP use case without appropriate configuration and lifecycle control.
For each option, assess semantic clarity, authentication, authorization, encryption where appropriate, error handling, observability and supplier support. A direct database write can bypass application validation and business rules; if such an approach is proposed, understand the supported contract and consequences before acceptance. Avoid undocumented dependencies on internal tables that a vendor may change during an upgrade.
[GEP] Select a supported, maintainable interface that meets the intended use. A modern protocol name does not compensate for missing transaction semantics, and a legacy mechanism needs explicit controls for its limitations. Record version compatibility and how changes will be coordinated between system owners.
Align master data before moving transactions
Material, equipment, unit, recipe and operation identifiers must have agreed meaning. Define where each identifier originates and how revisions, obsolete values and aliases are managed. A material code can be valid in ERP but unavailable or differently classified in MES. An equipment name can refer to a physical asset in one system and a production role in another.
Specify unit conversions and precision deliberately. Distinguish stored precision, displayed precision and rounding used in calculations. Confirm how decimal separators and locale settings are handled in machine-readable exchanges. Do not depend on a user's workstation locale to interpret a manufacturing quantity.
Sequence master-data changes and dependent transactions. If a new material revision must arrive before an order, define how the receiver detects and holds an order that arrives first. Preserve the revision actually used for execution rather than resolving every historical reference against today's master data.
Define confirmation in stages
Transport delivery, application receipt, validation, persistence and business completion are separate events. Decide which confirmation the sender needs before progressing. A message broker acknowledging storage does not prove that MES accepted an operation; an API returning successfully may indicate only that asynchronous processing began.
Specify observable states for pending, accepted, rejected and completed transactions. Where a transaction spans several systems, define partial success and compensation or recovery rules. A material movement that succeeded in one application but failed in another should become a visible reconciliation item, not disappear into an internal log.
[GUIDEGXP RECOMMENDATION] Write acceptance criteria using the final intended state and evidence. For example, “the receiving record contains the approved material revision and quantity, linked to the correct operation, with a traceable confirmation” is more useful than “the endpoint returns a success code.”
Engineer retries and duplicate handling
A sender may lose the response after the receiver has already committed a transaction. Retrying is then necessary but can create duplicates unless the design recognizes the transaction identity. Define idempotent behaviour where suitable: repeating the same intended request should not repeat a material consumption or create another completed operation.
Decide how the receiver handles a repeated identifier with different content. Silently treating it as an ordinary retry can conceal a conflicting correction. Establish whether corrections create a new linked transaction, require cancellation and replacement, or follow another controlled workflow. Preserve accountability and history.
Bound retry behaviour through the assessed operational need and service capabilities. Avoid infinite rapid retries that overload a recovering service. Define escalation, queue capacity, expiry and operator action. These parameters are project-specific engineering decisions; there is no universal GMP retry interval or permitted number of attempts.
Preserve ordering and time meaning
Transactions can arrive late or out of order even when each connection is reliable. An operation-complete event may arrive before an associated result, and a correction may arrive after a report has been generated. Define dependencies and whether the receiver waits, rejects, buffers or reconciles out-of-order information.
Distinguish source event time, transmission time, receipt time and processing time. Preserve the time basis and sufficient time-zone context for reconstruction. Time synchronization helps, but it does not replace transaction identifiers or ordering rules. A timestamp alone may not uniquely identify an event.
For process observations, retain quality information and define treatment of delayed values. A late observation should not be mistaken for a new current measurement. For manufacturing events, specify how the record shows both the original event and later correction or receipt where this distinction matters.
Make store-and-forward and reconciliation operational
Buffering can preserve data during interruption, but only within defined capacity and failure assumptions. Identify where data are buffered, whether the buffer survives restart, how overflow is detected and what prevents unauthorized modification. Define what happens when the outage exceeds the supported capacity.
Reconciliation compares expected and actual transactions or records. Select an appropriate basis: transaction identities, quantities, counts, state transitions or complete payloads. Counts alone cannot prove equivalence if one item is duplicated and another missing. The method should detect the discrepancies consequential to the intended use.
Assign the queue and reconciliation workflow to named operational roles. Provide enough context to investigate without editing databases informally. Define authorization for replay, correction and closure, and retain evidence of those actions. An integration is not maintainable if only its original developer can resolve a routine rejected message.
Test failure behaviour as well as normal exchange
| Test condition | Risk addressed | Required observation |
|---|---|---|
| Response lost after receiver commit | Duplicate execution after retry | Same transaction recognized without repeated business effect |
| Unknown material revision | Execution using incorrect master data | Visible rejection or controlled hold with assigned resolution |
| Messages delivered out of order | Invalid state or incomplete record | Defined buffering, dependency or reconciliation behaviour |
| Middleware restart with queued messages | Lost or repeated exchanges | Queue recovery and traceable end-to-end reconciliation |
| Payload version changed | Misinterpretation after upgrade | Compatible processing or explicit controlled rejection |
| Buffer limit approached or exceeded | Silent data loss | Detection, operational response and documented recovery limits |
Use controlled test data and representative configurations. Record expected and actual application states, not only network logs. Supplier interface tests may be reusable evidence after assessment, but site-specific mappings and cross-system workflows still need verification.
Worked example: a laboratory result that arrives twice
In an illustrative workflow, LIMS sends an approved laboratory result to MES for a defined manufacturing decision. MES commits the result, but its response is lost. LIMS retries the same transaction. Without a stable identity and duplicate rule, the receiver could create two result entries or repeat a downstream action.
The agreed contract includes a transaction identifier, sample and result identities, method or specification context where needed, result status and version. The receiver recognizes the repeated transaction and returns its existing outcome without repeating the business effect. If an amended result later arrives, it has an explicitly linked version and follows the approved correction workflow.
Acceptance testing covers the lost response, an unknown sample, a superseded result and a receiver restart. Reviewers can trace each final record to its source and explain why one message was treated as a retry while another was a controlled amendment. The example illustrates transaction design; the actual release decision remains governed by the site's quality process.
Coordinate security, change and support ownership
Limit interface access to required functions and data flows. Manage service identities, certificates and secrets through approved controls, including renewal and revocation. Record dependencies that can stop production when they expire. Security monitoring should identify relevant access failures without exposing sensitive payloads unnecessarily.
Assess interface changes jointly. A supplier upgrade, schema change, firewall rule or master-data revision can break a workflow outside the changed application. Maintain a compatibility register and a representative test environment. Define rollback and the handling of transactions already exchanged during a failed deployment.
Support agreements should identify who monitors each service, responds to rejected transactions and authorizes replay. Include cross-vendor escalation and access arrangements. The OT cybersecurity article develops infrastructure controls; the integration owner remains responsible for the manufacturing meaning of the exchange.
Check readiness before enabling production exchanges
Confirm that both system owners have approved the same contract and mapping version. Verify that monitoring reaches the people who can act, rejected transactions can be investigated, and replay has an authorized procedure. Establish the initial reconciliation baseline before the first production exchange. During cutover, distinguish test messages from production messages and prevent obsolete queues from being replayed inadvertently.
Record outstanding limitations with their operational controls and closure responsibility. A connection should not be released simply because its normal-path demonstration succeeded while recovery remains undefined. The release decision should account for the complete workflow, including the site's ability to support it after the project team leaves.
Apply the regulatory framework to the complete record path
[REGULATORY REQUIREMENT] Applicable GMP computerized-system and documentation requirements extend to the relevant configured workflows and records. In EU GMP, Annex 11, Chapter 4 and Annex 15 provide the principal framework discussed here. Where US Part 11 applies, evaluate electronic records and signatures in their predicate-rule context. A compliant source application does not automatically make its uncontrolled export or downstream transformation suitable.
[GUIDANCE] Data integrity guidance supports attention to completeness, accuracy and context throughout the data lifecycle. Define proportionate assurance through intended use and risk. Evidence should show that the integrated transaction works and that consequential failures are detected and resolved, rather than merely demonstrating that individual applications passed separate tests.
Continue with MES and historian ownership, Environmental Monitoring Systems for relevant monitoring interfaces, and the Automation & Digital Systems hub.
Primary references and status
Reviewed 23 September 2026. EudraLex Volume 4, with operative Annex 11 and Chapter 4 texts from 2011; 21 CFR Part 11; ISA standards catalogue; OPC Foundation public specifications; FDA drug CGMP data integrity guidance. Interface scenarios and acceptance criteria above are original engineering recommendations and require adaptation to the actual system.
