November 2026 · 10 min read

System integration for plant systems: the interfaces between the plant and the business, the three patterns, and how an integration project is run

What system integration covers on an industrial site, the interfaces between control systems, historian, MES, CMMS and ERP, the three patterns from point to point to publish and subscribe, how integration crosses the boundary between the plant and the business, and how to run an integration project so the interfaces survive handover. With a drawing of the patterns.

Systems IntegrationApplications

Key takeaways

System integration on a plant is making separately supplied systems, from the PLCs to the ERP, behave as one: the same tonnes, the same asset, the same timestamp, wherever they are read.
Most of the work sits at a handful of interfaces: control system to historian, historian to reporting, plant data to the CMMS, production to the ERP, and maintenance to finance and supply.
Point to point links grow with the square of the number of systems. A hub or a broker grows with the number of systems, which is why integration layers exist.
Every interface needs a written agreement, an interface control document, that says what crosses, which system is master of each field, and what happens when the link fails.
Data flowing up from the control system and out through a DMZ is routine. Anything writing back down into the control layer is a design decision, made deliberately and secured to IEC 62443.

A processing plant reports one tonnage in the shift report, a second in the ERP and a third in the metallurgical balance. All three are calculated correctly from the data each system received. The problem is that each system received the data by a different route, at a different cut-off, with a different rule for what to do when the weightometer dropped out. Nothing is broken, and the plant still cannot agree on how much it produced. That is a system integration problem, and it is the most common one there is.

This guide sets out what system integration covers on an industrial site, the interfaces most plants end up with, the three patterns for connecting systems, how integration crosses the boundary between the plant and the business, and how an integration project is run so the interfaces survive handover. It uses ISA-95 as the map, IEC 62443 and NIST SP 800-82 for the security boundary, and the plant protocols guide for the protocols themselves.

What system integration covers

An industrial site runs on systems that were bought at different times from different suppliers for different purposes. The PLCs and SCADA came with the plant. The historian was added for the process engineers. The maintenance system was chosen by maintenance, the ERP by finance, the laboratory system by the lab. Each does its own job well. Integration is the work of making them agree: the same asset number, the same product code, the same tonnes, the same time.

The ISA-95 levels give the work its shape. Levels 0 to 2 are the process, the instruments and the control systems. Level 3 is operations: production, maintenance, quality and inventory, with the historian and MES. Level 4 is the business: ERP, finance, supply. Most integration effort sits at two boundaries, between level 2 and level 3, where plant data is collected, and between level 3 and level 4, where operations becomes transactions.

The interfaces that matter

A plant ends up with a short list of interfaces, and almost every integration problem lives on one of them. Each carries a different kind of data on a different clock. Plant data arrives every second, production totals by shift, financial transactions at a daily cut-off. Many of the disagreements between systems come from mixing those clocks without saying how.

Interface	Between	What crosses	Typical method	What to watch
Control system to historian	PLC, DCS or SCADA to the data historian	Tag values, quality and timestamps, alarms and events	OPC UA, OPC DA through a gateway, a native collector or MQTT	Timestamp source, collection rate and what happens to data while the link is down
Historian to MES or reporting	Historian to production reporting, OEE and metallurgical accounting	Aggregated values by period, shift and product, downtime events	The historian's query interface, SQL or a REST API	Agreed aggregation rules, so one tonne figure is used everywhere
Control system or historian to CMMS	Plant data to the maintenance system	Run hours, counts, condition alarms that should raise work	A scheduled job or an event that raises a work request through the CMMS API	Every alarm raising a work order. Thresholds and a person in the loop matter
MES to ERP	Production to the business system	Production confirmations, consumption, inventory movements, quality results	ISA-95 style messages, the ERP's integration layer, files at a cut-off	Units, product codes and the timing of the daily close
CMMS to ERP	Maintenance to finance and supply	Purchase requisitions, goods receipts, costs to work orders, the asset register	Often built in when the CMMS is an ERP module. Otherwise an API or middleware	Two masters for one asset. Decide which system owns each field
Laboratory and weighbridge	LIMS and weighbridge to MES, ERP or both	Assays, sample results, gross and tare weights, tickets	A vendor interface, a database view or a file drop	Sample identity and the link back to the production period

Three patterns

There are three ways to connect systems, and most sites use all three. Point to point builds an interface for each pair. It is quick for the first link and expensive by the fifth, because with n systems there can be up to n(n-1)/2 interfaces, and an upgrade to one system can break several. Hub and spoke puts an integration layer in the middle. Each system connects once, and the mapping, routing and error handling live in one place where they can be monitored.

Publish and subscribe goes a step further for plant data. Systems publish to named topics on a broker, and anything that needs the data subscribes, without the publisher knowing who is reading. A new dashboard or analytics tool adds a subscriber and touches nothing else. This is the idea behind a unified namespace built on MQTT. It only works when the topic names and payloads are agreed and kept, because they are the whole design.

Fig. 1 · The same five systems connected point to point, through an integration layer and through a broker, with the number of interfaces each pattern needs

Pattern	How it works	Interfaces for n systems	Suits	What it costs
Point to point	Each pair of systems has its own interface, built for that pair	Up to n(n-1)/2. Ten links for five systems, forty five for ten	Two or three systems with stable, simple exchanges	Every new system or upgrade touches several interfaces, and nobody can draw the whole picture
Hub and spoke (middleware)	Every system connects once to an integration layer that maps and routes the data	n. One per system	Several business systems exchanging transactions, where mapping and error handling should live in one place	The layer becomes critical and needs its own owner, monitoring and support
Publish and subscribe (broker)	Systems publish data to topics on a broker and others subscribe to what they need, without knowing each other	n. One per system, and new readers add none to the publishers	Plant data shared by many consumers, as in a unified namespace over MQTT	Agreed topic names and payloads are the whole design. Without them it is point to point with extra steps

The fifth point to point interface costs more than the first four together, because each new link has to be checked against all the others.

Across the plant and business boundary

IT OT integration, sometimes called IT OT convergence, is integration across the boundary between the systems that run the plant and the systems that run the business. The two sides change at different speeds for good reasons. A control system is changed rarely and carefully because a change can stop production or remove a safeguard. Business systems are patched monthly. Integration has to respect both.

The settled design is a DMZ between the networks, with data flowing up and out. The historian, or a replica of it, sits where business systems can read it without reaching into the control network. That is described in the OT security guide with the zones and conduits of IEC 62443. Writes back down, such as a production target sent from MES to the control system or a recipe download, are possible and sometimes valuable. Each one is a design decision, with its own conduit, its own authentication and a plant owner who has agreed to it.

Running an integration project

Integration projects fail at the edges between suppliers more than in any one system. The control system integrator delivers a working historian, the software team delivers a working MES, and the interface between them was nobody's scope. The remedy is to treat each interface as a deliverable with an owner, a document and a test, from the first inventory to support.

Step	What is done	Output
Inventory	List every system, its owner, version and the data each one is master of	A system context drawing and a list of masters
Define the interfaces	For each exchange, write down what crosses, in which direction, how often and what happens when it fails	An interface control document per interface
Choose the pattern	Decide which exchanges go point to point, through middleware or through a broker	An integration architecture, with the security zones it crosses
Build and test in isolation	Each side is built to the interface document and tested against a simulator or a copy of the other side	Interface test records at FAT
Test end to end	The connected systems are tested together with real data, including failure and recovery	Records at SAT, with the error handling shown to work
Hand over and support	Monitoring, alerting, an owner for each interface, and a runbook for when it stops	Interfaces in the support model, not in a contractor's head

The interface control document

Each interface gets a short document that both sides build to. It is the contract between two suppliers, the reference for testing at factory and site acceptance, and the first page support staff read when the interface stops. The most important line in it is often the one that says which system is master of each field, because two systems that both think they own the asset description will overwrite each other forever.

Section	What it says
Parties	The two systems, their owners, and who supports each end
Data	Each field with its name, meaning, units, type, range and the system that is master of it
Direction and trigger	Who sends, who receives, and what starts an exchange: a schedule, an event or a request
Method	Protocol, message format, authentication and the network path through the security zones
Timing	Frequency, latency that is acceptable, and cut-off times for daily or shift totals
Errors	What counts as a failure, how it is retried, where rejected messages go, who is alerted
Tests	The cases that prove the interface works, including a dropped link and a duplicate message

Where integration goes wrong

No master named for shared data, so the asset register, product codes or cost centres drift between systems.
Interfaces built without failure handling, so a dropped link loses data silently and the totals stop agreeing.
Time handled differently on each side: local time against UTC, the end of shift against the end of day, daylight saving where the plant does not observe it.
Point to point links added one at a time until nobody can draw the whole picture or upgrade one system without breaking another.
Writes into the control system added for convenience, without a plant owner, a conduit or a test.
Interfaces handed over without monitoring, so the first sign of a failure is a wrong report a week later.
Integration left out of the scope of every supplier, because each assumed the other would do it.

Common questions

What is system integration?

Making separately built or supplied systems work together as one system, so that data entered or measured in one is available, correct and on time in the others. On an industrial site that covers the control systems, the historian, production and quality systems, the maintenance system and the business systems. The work includes designing the interfaces, building and testing them, and supporting them once they run.

What is IT OT integration?

Connecting the operational technology that runs the plant, such as PLCs, DCS, SCADA and historians, with the information technology that runs the business, such as ERP, maintenance and reporting systems. It is sometimes called IT OT convergence. The two sides have different priorities: OT puts availability and safety first and changes slowly, IT changes often and puts confidentiality high. Integration across the boundary is designed around a DMZ, one-way data where possible, and the zones and conduits of IEC 62443.

What does a system integrator do?

The term has two common meanings on industrial sites. A control system integrator designs, programs and commissions PLC, DCS and SCADA systems and connects them to the plant. An enterprise or software integrator connects business systems, such as MES, CMMS and ERP, to each other and to plant data. Many projects need both, and the boundary between them, usually at the historian or the DMZ, is where interface responsibility has to be written down.

What is ISA-95 and how does it relate to integration?

ISA-95, published internationally as IEC 62264, is the standard for integrating enterprise and control systems. It defines levels, from the physical process at level 0 to business planning at level 4, the activities at level 3 such as production, maintenance, quality and inventory operations, and the information exchanged between levels 3 and 4. Its main value in an integration project is a shared vocabulary and a checklist of the exchanges a plant will need.

What is the difference between point to point integration and middleware?

Point to point builds a separate interface for every pair of systems that exchange data, so the number of interfaces grows roughly with the square of the number of systems. Middleware, or an integration layer, connects each system once and handles mapping, routing and error handling centrally. Point to point is fine for two or three systems with simple, stable exchanges. Beyond that, the integration layer usually costs less to change and support.

What is an interface control document?

A document that defines one interface between two systems: the data that crosses with its meaning and units, the direction and trigger, the protocol and message format, the timing, how errors are handled and the tests that prove it works. Both sides build to it, so it is the contract between two suppliers or two teams, and it is the first thing support staff read when the interface stops.

Key terms

Plain-language definitions from our glossary for the concepts this article leans on.

System integration IT OT integration ISA-95 and the Purdue model Interface control document (ICD)Middleware Publish and subscribe MQTT Industrial DMZ

Standards and further reading

Related case studies and tools

Bridging OT and IT with custom software (case study)

Working through something like this?

See how we approach these initiatives, or tell us what you are dealing with.

Our experience Contact us