OT/IT Convergence Architecture: How to Connect PLC, SCADA, MES, and ERP Data

TL;DR

• OT/IT convergence connects operational and business systems through governed data exchange. PLCs own machine control, SCADA owns supervision, MES owns production execution, ERP owns business planning, and a decision layer reads across them to recommend actions.

• Identifier fragmentation prevents systems from recognizing that different machine, work order, and equipment IDs describe the same event.

• Latency requirements differ by layer. PLC control runs in milliseconds, while ERP planning runs across days or longer, so cloud paths cannot support control loops.

• Security segmentation must shape the architecture before broad data access begins. Industrial zones, controlled conduits, and an industrial DMZ limit which systems can communicate.

What OT/IT convergence means and why ownership boundaries matter

OT/IT convergence coordinates operational technology and information technology through shared data models, governed interfaces, and explicit write authority. Connectivity only moves data between systems. Convergence lets each system interpret that data consistently while preserving responsibility for control, execution, planning, and recommendations.

ISA-95, published internationally as IEC 62264, defines interfaces between manufacturing operations and business systems. It provides a useful functional hierarchy for assigning responsibilities, but each manufacturer must document authority for its specific systems and data objects. PLCs execute deterministic machine control. SCADA provides supervisory monitoring, alarms, and authorized operator commands. MES manages production execution records such as work in progress, genealogy, and quality results. ERP manages business records such as orders, inventory, costs, and production plans. Humble's guide to MOM, MES, and ERP explains the operational differences among the upper layers. A decision layer can analyze data across these boundaries and recommend actions, but it should not become another source of machine commands or transaction records.

Unclear ownership creates conflicting records and unsafe write paths. For example, a maintenance state may appear in SCADA, MES, and ERP under different identifiers. If no system owns the canonical state, each integration applies its own mapping and update rules. A network connection cannot determine which record wins, who may change it, or how downstream systems should reconcile competing updates.

Each boundary must also respect the operating time scale of the systems it connects. PLC control runs in milliseconds, SCADA supervision works in seconds, MES coordinates activity across hours or shifts, and ERP plans across days or months, as illustrated by this layered industrial systems mapping. ERP delays cannot enter a PLC control loop, and raw millisecond telemetry usually requires aggregation before business planning can use it. A production-ready architecture therefore assigns data ownership, write authority, latency requirements, and failure behavior at every boundary before selecting protocols or platforms.

Reference architecture: mapping PLC, SCADA, MES, ERP, and the decision layer

A production architecture should assign one authoritative owner to every command, transaction, and recommendation. The Purdue model provides useful boundaries across Levels 0 through 4. Some extended diagrams label external enterprise networks or cloud services as Level 5. An industrial DMZ commonly separates plant operations from enterprise services, although its exact placement and numbering vary by implementation.

Decision layer

The decision layer sits outside the formal Purdue hierarchy and consumes approved information from plant and enterprise systems. It reads contextualized information from ERP, MES, historians, and approved enterprise sources. It can prioritize production actions, explain constraints, and recommend schedule changes. It does not issue machine commands or become the official source for orders, inventory, or production records.

Humble Operations fits at this layer. Any accepted recommendation returns through the API or workflow of the system that owns execution. A schedule recommendation goes to ERP or MES, while a control change remains subject to SCADA and PLC authority.

Extended enterprise and cloud services

Extended enterprise and cloud services include cross-site analytics, cloud data platforms, and corporate identity infrastructure. Their interfaces consume approved data from Level 4 or services in the industrial DMZ. These applications should not write directly to plant controllers.

Level 4 Business planning

ERP owns customer orders, purchasing, inventory accounting, costing, and production planning records. ERP can create or revise planned orders, but MES decides how released work moves through plant execution. ERP and MES usually exchange orders, material status, completions, and consumption through APIs, messages, or integration middleware.

Level 3.5 Industrial DMZ

The industrial DMZ controls traffic between enterprise IT and plant OT. Proxy services, historian relays, jump hosts, and integration brokers can terminate sessions at the boundary so enterprise systems do not receive direct routed access to OT assets. The DMZ does not own production data or business transactions. It enforces the permitted transfer path.

Level 3 Site operations

MES owns production execution records such as dispatch status, work instructions, genealogy, quality results, and labor reporting. Plant historians own retained time series, but they do not determine machine state or authorize production. MES exchanges production transactions with ERP and consumes equipment events through SCADA, historians, gateways, or brokers.

Level 2 Supervisory control

SCADA and HMI applications own operator supervision, alarms, visualized process state, and authorized supervisory commands. SCADA may send setpoints or operating commands to a PLC, but the PLC validates and executes them. Northbound interfaces publish selected events and measurements without exposing unrestricted control access.

Level 1 Basic control

PLCs, distributed controllers, and safety controllers own deterministic machine logic, interlocks, sequencing, and output commands. Their write authority covers actuators and control variables within approved operating limits. PLC interfaces expose tags to SCADA or an edge gateway, but enterprise applications should not write to those tags directly.

Level 0 Physical process

Sensors report physical conditions, and actuators affect equipment or material. Level 0 produces raw signals rather than business records. Level 1 controllers interpret those signals and govern outputs.

Each boundary must preserve the timing of its owner. Control operates in milliseconds, supervision in seconds, MES over hours or shifts, and ERP over days or longer. Recommendations may cross several levels, but execution authority must remain local to the responsible layer.

Industrial protocols and where each one belongs

Protocol choice should follow the system boundary and timing requirement. Control networks need deterministic local exchange, while MES, ERP, and decision layers need contextualized data through interfaces that tolerate wider latency.

EtherNet/IP belongs between field devices, PLCs, and cell controllers. It supports cyclic I/O for control and explicit messaging for configuration or diagnostics, so architects should keep it within the control boundary rather than expose it directly to enterprise applications. Industrial protocol guidance describes its common control and inspection uses.

PROFINET also belongs inside machine and cell networks, especially where PLCs coordinate drives, remote I/O, and other equipment. A gateway usually converts PROFINET data into OPC UA or MQTT before SCADA, MES, or enterprise software consumes it.

Modbus TCP and Modbus RTU connect legacy PLCs, drives, meters, and controllers to an edge gateway or SCADA system. Modbus RTU requires a serial gateway when an Ethernet-based system must consume its data. Modbus TCP needs network isolation and a controlled gateway when data crosses into IT because the base Modbus protocol does not provide authentication, encryption, or a semantic information model.

OPC UA fits the boundary between PLC or SCADA environments and historians, MES platforms, and edge applications. Its browsable node model can carry names, types, relationships, and quality information, which reduces the mapping work required above the control layer.

MQTT with Sparkplug fits northbound data movement between edge gateways, brokers, MES applications, and cloud or decision systems. MQTT uses publish and subscribe messaging for event distribution. Sparkplug adds conventions for industrial topic structure, state, and payloads. Neither should carry deterministic control commands that must execute within a machine cycle.

MTConnect fits CNC monitoring boundaries where machine status, programs, alarms, and production counts must reach a historian or MES. Modern CNC equipment may expose MTConnect directly, while older controls usually need an adapter. Machine connectivity guidance describes MTConnect as structured machine tool data delivered over HTTP.

REST APIs belong between MES, ERP, analytics, and decision layers. REST works well for orders, schedules, master data, recommendations, and status updates, but request and response behavior makes it unsuitable for control loops. The guide to AI production scheduling and ERP integration examines API, database-view, middleware, and field-mapping choices at this boundary.

Modbus and OPC UA create very different contextualization workloads. A Modbus register such as 40021 carries meaning only when documentation maps it to an asset, unit, and operating state. An OPC UA node can expose much of that context directly. Gateways can translate the transport, but you must still define canonical asset identifiers and production relationships before downstream systems can use the data reliably.

Integration patterns compared: point-to-point, middleware, unified namespace, and historian-forwarding

Choose an integration pattern by comparing failure behavior, timing, security boundaries, and long term engineering cost. A connector that works for one machine may become difficult to govern across several plants.

Point-to-point integration fits a narrow interface with stable schemas and clear ownership. Its blast radius grows with every bespoke dependency. A schema change in MES may require repairs in ERP, reporting, and analytics connectors that each interpret the same field differently.

A unified namespace reduces those direct dependencies by giving each asset and event a shared semantic address. However, the namespace still needs canonical identifiers and an authoritative source for each event. Identifier mismatches can prevent an analytics model from connecting records that refer to the same asset or event. One published case example of identifier fragmentation describes SCADA, MES, and ERP records that used different identifiers for the same production interruption. Treat the example as an illustration rather than independent evidence because the source does not provide enough primary documentation to verify the reported outcome.

Middleware works well when existing systems need protocol translation, transformation, and controlled routing without adopting a broker centered namespace. Historian forwarding serves a narrower purpose. It preserves historical records and feeds analytics, but it should not become the path for control commands or MES execution writes. Many architectures combine these patterns rather than selecting one for every boundary.

Data contextualization: from raw tags to decision-ready information

Contextualization gives raw operational data a consistent meaning across systems. Connectivity can move a PLC tag into SCADA, MES, or ERP, but the receiving system still needs to know which asset produced the value, what the value measures, and which production event it belongs to.

An asset hierarchy locates each signal within a shared structure such as enterprise, site, area, line, and work cell. Tag mapping then translates controller specific names into defined attributes. A tag named PMP07_RUN might become the operating state attribute for Pump 07. The mapping should preserve the original tag and engineering units so users can trace normalized data back to its source.

Canonical IDs connect records that use different identifiers for the same asset or event. One published identifier-fragmentation example describes SCADA recording PMP-07, MES associating the interruption with work order WO-4471, and ERP assigning the cost variance to EQ-2047-B. The source presents this as a case example but does not provide primary records that independently verify it. Without a canonical relationship among those records, an analytics model could treat one production interruption as several unrelated events. An authoritative model must also specify whether SCADA, MES, or another application owns each event type when systems publish conflicting records.

Timestamp normalization preserves event order across layers that use different clocks and production calendars. SCADA may record local machine time while MES organizes events by shift and ERP uses a business date. The contextual layer should retain the source timestamp, convert events to a common time basis, record the applicable time zone, and associate each event with the correct shift or work order. These rules prevent a stop that crosses midnight or a shift boundary from appearing as two separate incidents.

Data quality flags tell downstream applications whether they can trust each value. Every record should carry a status such as good, bad, stale, or interpolated, and downstream calculations should preserve that status rather than silently treating every value as valid. The exact flag definitions, propagation rules, and timestamp synchronization requirements need verification against the applicable industrial standard and each vendor implementation. The available sources do not establish a universal convention for those controls.

Latency, reliability, and the edge/cloud boundary

Control loops must close within the plant network. PLCs and machine controllers act in milliseconds, while SCADA monitoring and alarms generally operate in seconds. MES workflows run across hours or shifts, and ERP planning spans days or months. These different operating timescales prevent one latency profile from serving every layer.

Cloud services should not sit in a safety-critical or deterministic control loop between a sensor, PLC, and actuator unless the control system has been specifically engineered and validated for that architecture. Network routing, congestion, service availability, and geographic distance introduce variable delays that hard real time control cannot tolerate. Local controllers should retain control authority, and plant systems should continue operating when the cloud or wide area network becomes unavailable. Edge processing supports that independence because equipment does not need a remote response before acting.

Central systems fit workloads that tolerate longer response times. Cloud or data center services can support historical analysis, cross plant reporting, model training, and planning. A decision layer can also run centrally when it recommends actions rather than issuing time sensitive control commands. Each recommendation should return through the authorized MES, ERP, or operator workflow instead of bypassing local write controls.

Store-and-forward buffering belongs at the edge gateway, local broker, or historian boundary. When an upstream connection fails, the local component should retain timestamped records and replay them after service returns. Receiving applications must detect duplicate deliveries and preserve event order. Buffer capacity should cover the longest credible outage, and acceptance testing should verify that local control continues while disconnected.

Reliability and time synchronization requirements need explicit verification. Availability targets should reflect the consequence of each service failing rather than applying a 99.999% availability target to every component. Architects should confirm Precision Time Protocol and Network Time Protocol requirements against relevant standards, including IEEE 1588 where applicable, before specifying accuracy or event ordering guarantees. The available evidence does not support a universal uptime figure or synchronization tolerance for every OT environment.

Cybersecurity architecture for a converged OT/IT environment

OT security architecture must protect safety and operational continuity alongside data confidentiality and integrity. The relative priority of those objectives varies by process and consequence. An unavailable controller or HMI can stop production or affect a physical process, so controls designed for enterprise IT require OT-specific testing before deployment. Generic IT tools can therefore cause problems when they quarantine devices, force restarts, or scan production controllers without accounting for operational consequences.

ISA/IEC 62443 defines zones and conduits as a method for grouping assets and controlling communication between groups. A zone groups assets with similar functions and risk, while a conduit defines the permitted communication between zones. Each boundary should deny traffic by default and allow only documented protocols, endpoints, and directions. Engineers must define failure behavior through a safety and operability review because abruptly blocking communication can be unsafe for some processes. IEC 62443 guidance also calls for stronger physical separation at higher security levels.

The Purdue model helps place those boundaries across the manufacturing stack. PLCs and safety systems occupy the control levels, SCADA occupies the supervisory level, and MES and plant historians typically occupy site operations. ERP, enterprise applications, and cloud services sit above them. Many reference architectures place an industrial DMZ between plant operations and business IT, sometimes labeling it Level 3.5. A common design uses separate OT-facing and IT-facing firewall boundaries, but the required topology should follow the site's risk assessment and applicable security requirements.

Every exchange across the industrial DMZ should terminate at an intermediary service and begin a separate session on the other side. An enterprise application should never receive direct routed access to a PLC, SCADA server, or engineering workstation. Common intermediary services include historian relays, data brokers, patch staging servers, and controlled jump hosts.

Historian exchange should use a documented, least-privilege flow through the industrial DMZ. Depending on the products and security design, an approved relay may pull from an operations historian or receive data pushed from a lower zone. An industrial DMZ relay pulls permitted telemetry from the operations historian and provides a separate copy to enterprise consumers. Business applications cannot use the same route to send commands into the plant. A data diode can enforce one way transfer when a process requires stronger separation.

Least privilege must govern both people and services. Each user needs a unique identity, and roles should restrict engineering changes to approved personnel. Remote maintenance should pass through an industrial DMZ jump host with multifactor authentication, explicit approval, session recording, and a limited access window. Service accounts should receive access only to the required tags, APIs, or message topics.

ICS aware monitoring should observe industrial traffic without disrupting production. Passive inspection can identify unexpected Modbus writes, unauthorized OPC UA sessions, or unusual EtherNet/IP commands. Standard IT vulnerability scanners can overload older controllers or trigger unstable protocol implementations, so OT engineering should approve any active scan.

A decision layer belongs above the OT control zones and behind these controls. It should consume approved data through a historian relay, broker, or enterprise API rather than opening a direct path to plant assets. Any recommendation sent back to MES or ERP should use an authenticated, allowlisted interface, while PLC, SCADA, MES, and ERP retain their existing write authority.

Legacy constraints and why convergence projects fail

Identifier fragmentation can invalidate analytics even when each source record is internally accurate. The earlier published predictive-maintenance example attributes poor recommendations to missing mappings among SCADA, MES, and ERP identifiers. Because the source does not provide primary project records, architects should use it as an illustration and validate the same failure mode against their own data.

Point-to-point integration makes those identity problems harder to correct. Each connector embeds assumptions about tag names, asset IDs, timestamps, and field structures. When MES changes a work order schema, every dependent interface may require separate remediation. A canonical model or unified namespace limits that dependency by giving each asset and event a stable identity outside any individual source system.

Legacy controllers add translation work, but hardware replacement is not always necessary. Protocol middleware and legacy OPC DA gateways can bridge older PLC environments into modern interfaces. Architects should contain protocol translation near the OT boundary so downstream applications consume a consistent model rather than maintaining separate mappings for each controller family.

Security reviews cause redesign when architects defer them until broad data access is ready. An approved architecture may require an industrial DMZ, restricted outbound connections, read only access, or historian forwarding instead of direct queries into the control network. If the selected integration pattern cannot operate within those constraints, you may need to replace connectors, change hosting locations, and repeat validation.

Historian preservation must shape the project plan before migration begins. Long running historians contain operating states, failures, and maintenance outcomes that newer platforms cannot recreate. Build the canonical asset model before moving or retiring historian data, and preserve source timestamps and quality indicators during extraction. Predictive-maintenance models need enough representative failure and normal-operation examples to support training and validation. The required history varies with failure frequency, asset behavior, operating conditions, and modeling method, so plants should assess event coverage before setting a collection period or performance target.

See How Humble Fits Your Existing Stack

Humble Operations adds a decision layer above your PLC, SCADA, MES, and ERP stack. Each existing system keeps its execution authority, while Humble uses connected operational data to recommend prioritized actions.

During evaluation, verify that each Humble Operations recommendation records its source evidence, applicable constraints, and approval history. You can move from a production signal to an informed action without replacing core infrastructure or repeating the same analysis across meetings.

Use the Humble Operations fit test for an initial assessment of whether a decision layer matches your current architecture.

Phased implementation plan with acceptance gates

Phase 1. Establish the protocol and connectivity baseline

Start with a limited, read-only path for representative PLC, SCADA, MES, and ERP data. Record each interface owner, protocol, sampling requirement, and expected latency. Test legacy gateways under normal production load, including local buffering and replay after a connection loss.

The acceptance gate passes when approved data reaches an isolated staging environment with intact identifiers and timestamps. PLC scan behavior, SCADA alarms, and production control must remain within limits approved by OT owners.

Phase 2. Build and test the canonical model

Assign one canonical identifier to each asset, material, work order, and production event included in the pilot. Define which source controls each field when SCADA, MES, and ERP records conflict. Normalize timestamps so events remain ordered across shift changes and different system clocks.

The acceptance gate passes when every test event maps to the correct asset and work order. Duplicate records must resolve according to documented authority rules, and any unresolved exception must block advancement.

Phase 3. Validate security segmentation

Validate network zones and permitted data paths before granting broad access. Route cross boundary traffic through the industrial DMZ, restrict service accounts to required operations, and confirm that analytics access cannot reach PLC control functions. Postponing OT security review can force connector, hosting, and network changes after implementation begins. A published integration case discussion reports delays of six to twelve months, but the source does not provide enough project evidence to treat that range as a general benchmark.

The acceptance gate passes when approved flows succeed and prohibited flows fail during joint OT and IT testing. Recovery tests must also show that connection loss does not interrupt local control or erase buffered records. Broad data access begins only after both groups approve the evidence.

Phase 4. Activate the decision layer in shadow mode

Run the decision layer without write authority. Compare its recommendations with actual operating decisions, and retain the source records and constraints behind each recommendation. Users should be able to reject a recommendation without changing MES, ERP, SCADA, or PLC behavior. A related guide explains how to replace spreadsheet production tracking without replacing ERP through a bounded pilot.

The acceptance gate passes when the decision layer meets predefined accuracy and response criteria on representative cases. Each recommendation must remain traceable to its evidence. Any later write back requires a separate change review, bounded permissions, and an OT approved rollback procedure.

Vendor and architecture evaluation criteria

Your required ownership boundary should determine which platform category fits. Evaluate each product's deployment model, write authority, integration depth, and security posture.

• MOM and MES platforms should own production execution. Verify whether the platform manages work orders, material genealogy, quality records, and machine states. Confirm its cloud, local, and edge deployment options, including behavior during a network outage. Document every permitted write into PLC or SCADA environments. Require protocol support, identity controls, audit logs, and evidence that the deployment respects your IEC 62443 zones and conduits.

• ERP native AI should operate within the ERP security and data model. Epicor Prism is an example of this category, subject to verification against Epicor's current product documentation and the modules in your deployment. Verify which ERP modules its agents can access and whether they can use external MES, historian, or SCADA data. Check whether an agent recommends an action or executes it. You should also test approval controls, audit records, data residency, and separation between users with different ERP roles.

• Connected worker platforms should improve human tasks at the point of work. Tulip Interfaces and Augmentir are commonly evaluated in this category, but you should verify their current deployment, workflow, and integration capabilities directly with each vendor. Confirm how each platform captures operator input, distributes instructions, and handles disconnected devices. Inspect its connectors to machines, MES, and ERP systems. Limit write authority to documented workflows, and test device identity, user permissions, and change history.

• Independent decision layers should combine data without taking execution ownership. Humble Operations is positioned as an independent decision layer that leaves PLC control, MES execution, and ERP planning authority in their existing systems. Verify that separation during technical evaluation. Verify how the platform resolves identifiers across sources and explains each recommendation. Test latency, stale data handling, approval rules, and every write back path before granting production access.

Vendor diagrams require direct technical validation. The available research for this guide does not independently verify architecture claims for Palantir Foundry, Plex, or Infor CloudSuite. Request current deployment diagrams, connector documentation, security certifications, and interface specifications directly from each vendor. Use a proof of concept to test outage behavior, schema changes, and authorization boundaries against your own environment.

Book a Call with Humble to Map Your Architecture

If you are evaluating a decision layer, schedule an architecture discussion with Humble Operations to examine where it could fit above your existing ERP and MES. The conversation can cover data interfaces, system ownership, write authority, security boundaries, and an initial use case.

Humble Operations is designed to work with the current manufacturing stack rather than replace it. During evaluation, confirm how its decision layer prioritizes recommendations, records supporting evidence, and applies operating constraints.

Newsletter

Get ongoing coverage of OT/IT architecture and manufacturing decision intelligence in the Humble Operations newsletter.

Frequently asked questions

What is OT/IT convergence?

OT/IT convergence connects industrial control and production systems with business systems under shared data, security, and governance rules. ISA-95 provides the functional hierarchy for separating machine control, manufacturing operations, and business planning. Convergence preserves those responsibilities while enabling governed data exchange between them.

Who owns data at each manufacturing layer?

In a typical ISA-95-aligned architecture, PLCs execute control logic and maintain the controller state used to govern equipment. SCADA manages supervisory information, alarms, and authorized operator commands. MES manages production execution records, including work in progress and genealogy. ERP manages orders, inventory, costs, and business plans. Each system should retain write authority for its assigned function.

Which protocols connect PLC, SCADA, MES, and ERP systems?

Protocol choice depends on the boundary. OPC UA commonly exchanges structured data between controllers, SCADA, and MES. Modbus connects many legacy devices but requires external tag definitions. MQTT supports brokered edge telemetry, while REST APIs commonly connect MES, ERP, and decision applications. IEC 62443 governs how you secure these connections rather than prescribing one protocol.

How long does OT/IT integration take?

A contained protocol audit and pilot can take weeks, while plant-wide contextualization and security work can take months or longer. Asset count, legacy interfaces, identifier quality, and acceptance testing determine the schedule. ISA 95 defines functional boundaries but does not prescribe an implementation duration.

Can legacy PLCs be integrated without replacement?

Gateways can often expose legacy PLC data through OPC UA, MQTT, or another supported interface without changing the controller. Engineers must map register addresses into meaningful asset and production identifiers. IEC 62443 controls should restrict gateway access and prevent enterprise applications from writing directly to PLCs.

What is an industrial DMZ?

An industrial DMZ separates plant operations networks from enterprise IT. Services such as historian relays, jump hosts, and update servers terminate traffic inside this intermediate zone instead of allowing direct routed access. The IEC 62443 zone and conduit model supports deny by default boundary controls and tightly governed communications.

Where does a decision layer like Humble fit compared with MES or ERP?

A decision layer consumes governed data from MES, ERP, and operational sources, then recommends prioritized actions. MES still controls production execution, and ERP remains authoritative for business planning. Humble Operations occupies this decision layer and can return approved recommendations through existing interfaces without replacing the systems of record defined by ISA 95.

The architecture decision that matters most

Successful OT/IT convergence depends on explicit authority and a canonical data model. Each data object needs a stable identity and an authoritative source with defined write permissions. Otherwise, additional connectors reproduce conflicting asset names and timestamps across more systems. Tool choice cannot resolve those governance decisions.

A decision layer should enter after those boundaries and meanings become dependable. It can evaluate converged operational data against business constraints, then recommend prioritized action while execution systems retain write authority. Humble Operations serves this role above existing ERP and MES infrastructure, with recommendations that should remain traceable to source evidence and documented constraints. Manufacturers can add that capability without reopening the underlying control architecture.