SCADA and PLC integration: getting plant data out without disturbing anything

Why the connecting is harder than the collecting

Most people approaching a plant data project budget for sensors. The sensors are rarely the problem. The larger and far less predictable expense is connecting what you collect to the systems that already exist: the controllers running the process, the supervisory software the operators watch, the historian the process engineers trust, and the maintenance and business systems where decisions actually get made.

That work is specific to your site, dependent on documentation that may be wrong, and gated by people whose primary responsibility is keeping production running. It is where plant data projects most often stall, and it is worth understanding before committing to one.

What is already there

A typical site has accumulated systems over decades, each solving a problem at the time, rarely designed to work together.

The opportunity is almost never to replace any of these. It is to connect them, so that a reading from a machine can reach a decision without being retyped into a spreadsheet.

The levels, and where the boundary belongs

Industrial architecture is conventionally described in levels, from the physical process at the bottom through control, supervision and site systems to enterprise software at the top. The model is idealised and few real plants match it cleanly, but it is useful for one reason: it makes explicit where the boundary between operational and business systems sits, and therefore where the controls belong.

The essential idea is that there should be one place where the plant network meets the business network, that it should be designed rather than accidental, and that data should flow outward from the plant without anything on the outside being able to initiate a connection inward.

OT and IT have different priorities, and both are right

Integration projects frequently become difficult for cultural reasons rather than technical ones, and it helps to understand why the two sides behave differently.

Neither position is unreasonable. A production engineer who resists adding a device to a control network has usually seen what happens when something unexpected disturbs it. An IT manager who resists an unpatched twenty-year-old system on their network is likewise correct about the risk.

Integration succeeds when both are engaged early, with a design that respects both concerns: nothing that can disturb the process, and nothing that creates an unmanaged path into it.

Where to take the data from

There are usually several possible sources, and the right one is often not the most obvious.

The default should be the least intrusive source that carries what you need. Reading from a historian disturbs nothing and is frequently sufficient. Going directly to a controller should require a reason.

Where no interface exists at all, external sensing is covered in detail in our guide to retrofitting legacy machines, and what to do with the resulting data in predictive maintenance, and the protocol layer is covered in OPC UA, MQTT and Modbus.

Read-only, and what it buys you

A collection system that only reads cannot write a wrong setpoint, cannot disturb a control loop, and cannot be the cause of a stoppage. That removes an entire category of risk, and more importantly it removes it from the conversation with the people whose approval you need.

It is worth making read-only demonstrable rather than merely asserted. A gateway configured with read-only credentials, on a network path that permits only the traffic it needs, is a different proposition from one that is simply not currently configured to write. The first can be shown to a sceptical engineer; the second requires them to trust you.

Where writing genuinely is required, it should be a separate project with its own assessment, its own boundaries and its own testing, rather than an extension of a monitoring scope that was approved because it was harmless.

One further note on read-only access: it is worth distinguishing between a system that does not write and a system that cannot. Configuration can be changed, by someone with good intentions and a deadline, and a monitoring system that merely happens not to write today may acquire the capability quietly. Enforcing the restriction at the account level and at the network level means the constraint survives configuration changes and staff turnover, which is what makes it something you can still assert truthfully in two years.

Tags, registers and the recovery of meaning

Whatever the source, you will encounter the same problem: the data is identified by names or numbers whose meaning lives in documentation that may be incomplete, outdated or missing.

Register maps for older equipment are frequently wrong, because the equipment was modified and the document was not. SCADA tag names accumulate history: abbreviations that made sense to someone who has left, numbering that reflects a layout that has since changed, duplicates from a system migration. Untangling this is real engineering work and should be budgeted rather than assumed away.

The reliable method is empirical. Take a value you can independently verify, because it appears on the machine’s own display or because you can cause it to change in a known way, and confirm your pipeline reports the same thing. That single step resolves scaling factors, signed and unsigned confusion, units and word order together.

Then record what you establish, in a form that outlives the project. A mapping document that says what each tag means, what units it is in, how it was verified and when, is one of the more valuable artefacts an integration produces.

Timestamps: the detail that decides whether data is usable

This is routinely treated as an implementation detail and it determines whether your data can answer questions later.

Timestamp at the source, not on arrival. If a gateway buffers during a network outage and then timestamps everything as it forwards, an hour of readings will appear to have occurred in the same second. The data most affected is the data around the outage, which is frequently the data you most want.

Synchronise clocks. Correlating an event in one system with an event in another is impossible if their clocks disagree by minutes. Network time synchronisation is adequate for most process data; where sub-second correlation matters, more precise mechanisms exist and need designing in rather than adding later.

Decide on a timezone convention and apply it everywhere. Storing local time invites an annual hour of duplicated or missing data when clocks change. Storing in a single absolute reference and converting for display avoids an entire class of confusion.

Handle out-of-order arrival. Buffered data arriving after live data is normal in any system with intermittent connectivity. The storage layer must accept it rather than rejecting it as stale, and anything computing aggregates must cope with history arriving late.

Alarms are data too, and usually neglected

Most integration projects focus on process values and overlook the alarm and event record, which is frequently the most information-dense thing a plant produces.

Alarms record what the control system itself considered abnormal, when, and often what an operator did about it. That is a labelled history of plant behaviour, assembled continuously, at no additional cost, and it is sitting in the SCADA system already. For anyone trying to understand why a machine misbehaves, or to correlate a condition signal with something that actually happened, it is far more useful than another temperature trend.

It is also where a familiar problem shows up. Many plants suffer from alarm flooding: so many alarms configured, so many of them not genuinely actionable, that operators acknowledge them reflexively and the signal is lost. Where that is the case, extracting the alarm history reveals it plainly, since the distribution of alarms by tag makes the handful of nuisance sources obvious.

That finding is often worth more than the project that produced it. Reducing a nuisance alarm rate improves operator attention across the whole plant, which is a safety and reliability benefit that no amount of additional sensing delivers. Standards exist for alarm management, and where a site is struggling with this, addressing it may be a better investment than adding measurements.

For integration purposes, the practical points are: capture alarm and event records alongside process values, preserve the acknowledgement and operator action information rather than only the alarm itself, and keep them indefinitely, since they are small and their value is entirely in the history.

Data quality, which nobody budgets for

Real plant data is messier than any design assumes.

• Gaps. Networks drop, gateways restart, devices are switched off during maintenance. Absence of data is not zero, and any calculation that treats it as such will be wrong in an interesting way.
• Duplicates. Retries and reconnections produce them. Deduplication needs a stable identifier per reading rather than a guess based on timing.
• Frozen values. A sensor that has failed frequently reports its last value forever rather than reporting nothing. This looks like a perfectly stable process and is the most dangerous failure mode in the set.
• Out-of-range readings. A disconnected input may read zero, full scale, or something arbitrary. The pipeline should recognise and flag rather than record and average.
• Quality flags. Some protocols carry an indication of whether a value is good. Where available, this should be preserved through the pipeline rather than discarded in favour of the number alone.

Deciding how each of these is detected and represented is part of the integration design. Systems that ignore them produce analyses that look authoritative and are quietly wrong.

How much data, and where to keep it

Plant data accumulates faster than expected, and storage decisions made casually are difficult to reverse because you cannot retroactively keep what you discarded.

The first question is what actually needs recording. A process value sampled every second, from a few hundred tags, across a year, is a substantial quantity of numbers, most of which describe a process that was not changing. Historians handle this with compression schemes that store a value only when it deviates from a predicted path by more than a set amount, which reduces volume dramatically while preserving the shape of what happened.

That compression has a consequence worth understanding: the data you read back is an approximation of what was recorded, within a tolerance you chose. For trending and for most analysis this is entirely appropriate. For anything requiring exact reconstruction, such as an investigation into a specific event, the tolerance may matter, which is an argument for recording critical tags with tighter settings rather than applying one policy everywhere.

On site, or in the cloud

Both, usually. Local storage at or near the plant gives resilience when the link fails and keeps the operational view working regardless of what is happening upstream. Central storage supports comparison across sites, longer retention and analysis that would be awkward on plant hardware.

The sensible pattern is local retention sized for a realistic worst-case outage plus whatever the operational views need, with forwarding to central storage for anything requiring longer history or cross-site comparison. Where data residency requirements apply, they constrain this and should be raised at the start.

Security with equipment that cannot be secured

Much industrial equipment was designed when physical access was the security boundary. It has no authentication to enable, no encryption to configure and no patches available. Connecting it to anything invalidates the assumption it was built on.

The protection therefore comes from the architecture around it.

• Segmentation. Control networks separated from business networks, with a designed crossing point rather than a flat network.
• One direction. Data leaves; nothing initiates a connection inward. An outbound-only publishing pattern achieves this cleanly.
• Read-only collection. A system that cannot write cannot be used to write.
• Least privilege. Accounts with access to exactly what they need.
• Monitoring the boundary. Knowing what crosses, and being alerted when something unexpected does.
• Compensating controls, documented. Where a device cannot be secured, recording what protects it instead, so the reasoning survives an audit and a change of staff.

The recognised framework in this area is IEC 62443, which defines security levels and zones for industrial automation. Larger organisations often have internal standards derived from it. Where either applies, raise it at the start, because it constrains architecture rather than decorating it. We are engineers rather than an assessment body; where formal certification is required that is separate accredited work.

Getting data into the systems that use it

Collection is only useful if the result reaches somewhere that changes a decision.

Into the maintenance system. This is usually the highest-value integration, because it turns an alert into a work order in the queue the maintenance team already works from, rather than an email nobody owns.

Into the historian. Where one exists and is trusted, adding new measurements to it means the process engineers can use existing tools rather than learning another interface.

Into MES or ERP. Where production numbers need to join business reporting. This is usually the most constrained integration, since those systems are change-controlled and their owners are rightly cautious. That work has its own article: OT/IT integration with MES, ERP and historians.

Into dashboards. Which are valuable for the floor and for supervision, provided they are placed where the people who can act will see them. See cloud and dashboards.

Naming things consistently across systems

Once data from several sources reaches one place, the naming problem becomes visible. The SCADA system calls a motor one thing, the maintenance system calls the same asset something else, and the new sensing system calls it a third thing. Nobody can join the three without a translation table held in somebody’s head.

Resolving this is more valuable than it sounds, and it is far cheaper to do at the start than to retrofit across years of accumulated records.

The approach that works is to establish one identifier per physical asset, chosen to match whatever the maintenance team already uses, since they are the people who will be reading alerts and raising work orders. Every system then references that identifier, and the mappings from each system’s internal naming to it are recorded once and maintained deliberately.

Alongside asset identity, agree a convention for measurement naming. Consistency in how a measurement is named across machines matters more than the elegance of the convention itself: it is what allows a query to ask the same question of fifty assets rather than fifty differently phrased questions. Include the unit in the name or alongside it, because ambiguity about units causes expensive confusion, and apply the convention uniformly rather than allowing each integration to invent its own.

Where multiple teams or vendors will publish into a shared system, this becomes a governance question rather than a technical one: somebody has to own the convention and apply it when new sources arrive. Specifications such as Sparkplug B exist partly to remove this problem by defining the structure in advance, as discussed in our article on industrial protocols.

What happens when something breaks

An integration is a production system whose failure will be noticed, and it is worth designing for its own failure modes rather than only for the plant’s.

A source stops responding. The pipeline should distinguish this from a value that has not changed, flag it, and continue with the other sources rather than stalling.

The gateway restarts. It should resume without manual intervention, recover its configuration, and not lose buffered data. Testing this means actually power-cycling it rather than reading the specification.

The upstream system is unavailable. Buffering handles short outages; for longer ones, the behaviour when the buffer fills should be a decision rather than an accident.

A certificate expires. This produces a confusing outage, often long after the person who installed it has moved on. Recording expiry dates somewhere institutional, and alerting before they arrive, avoids an entirely predictable incident.

Someone changes something in the SCADA system. Tags get renamed, reconfigured or removed during ordinary plant work, with no knowledge that something downstream depends on them. Monitoring for tags that have stopped reporting catches this quickly, and documenting the dependency reduces how often it happens.

That last one is the most common cause of a working integration quietly breaking, and it is organisational rather than technical. The remedy is that whoever maintains the SCADA system knows the integration exists and what it depends on.

Change management, which is not optional in OT

Changes to plant systems go through a process, and for good reason. An integration project that treats that process as an obstacle will be slow and will make enemies; one that works with it will be slow and will succeed.

Practically, that means documenting what will be connected and how before asking for approval, having a tested rollback for every change, scheduling work in agreed windows rather than requesting them at short notice, and being able to state exactly what traffic the new system generates and what happens if it is switched off.

The last point is worth emphasising. A system that can be disconnected at any moment with no effect on production is a much easier approval than one whose failure mode is unclear.

Commissioning checklist

• Verify every mapped value against something independently observable, not just that a number appears.
• Confirm the controller is unaffected by the request rate, measured rather than assumed.
• Disconnect the network and confirm buffering, then reconnect and confirm the buffered data arrives with correct timestamps.
• Restart each component and confirm recovery without manual intervention.
• Confirm read-only at the network level, not only in configuration.
• Check clock synchronisation across every component that timestamps anything.
• Simulate a sensor failure and confirm the pipeline flags it rather than recording the frozen value as real.
• Record credentials and certificate expiry dates somewhere that survives staff changes.

Building the internal case, and who has to agree

Integration projects need more internal agreement than most engineering work, because they touch systems owned by different people with different incentives. Understanding who those people are, and what each of them needs to hear, does more for the schedule than any technical decision.

The pattern across that table is that everyone is asking a version of the same question: what can this break, and can it be undone. A design that answers both plainly gets approved faster than one that is technically superior and harder to reason about.

The strongest single position is being able to say that the system can be switched off at any moment with no effect on production. It converts the conversation from risk assessment to cost-benefit, which is much easier ground.

A worked example

A site with a modern SCADA system covering half the plant, a historian with several years of data, a maintenance system in use, and a dozen older machines connected to none of it.

A sensible approach: take process values from the historian and the SCADA system rather than from controllers, because both already have them and neither adds load. Add external sensing on the dozen older machines for run state and mechanical condition, feeding a gateway per area. Publish everything outward through a single controlled boundary point using an outbound connection, with no inbound path to the plant network. Normalise naming across both sources so consumers see one consistent structure rather than two conventions. Route condition alerts into the maintenance system as work orders. Keep the historian as the system of record for process data, and add the new measurements to it rather than creating a parallel store nobody trusts.

The work that takes longest in a project like this is rarely the connection. It is establishing what the existing tags actually mean, agreeing the boundary design with the people who own the networks, and getting the maintenance system integration through change control.

Mistakes worth avoiding

• Going to the PLC by default. Higher-level sources are usually easier, safer and already aggregated.
• Trusting the documentation. Verify empirically; budget for it.
• Timestamping on arrival. Corrupts exactly the data around outages.
• Treating gaps as zero. Produces confidently wrong analysis.
• Flat networks. Convenient during commissioning, and a standing risk afterwards.
• Skipping the network owner. They will be involved eventually, and later is more expensive.
• Building a parallel data store nobody trusts. If a historian exists and is trusted, add to it.
• Writing back because it is technically possible. Different risk category, separate decision.

Working with an integrator: questions worth asking

Whether you use us or somebody else, these questions separate suppliers who have worked in live plants from those who have worked in demonstrations.

• Where will you take the data from, and why there? A supplier who reaches straight for the PLC without considering the historian or SCADA system may not have thought about controller load.
• Does anything write to our control systems? The answer should be no, or a precise account of exactly what writes, when, and what happens if it writes the wrong thing.
• How do you verify that a tag means what the documentation says? “We read the register map” is not the same answer as “we confirm against a value you can independently observe”.
• Where does the timestamp come from? If the answer is the ingestion point, buffered data will be misattributed.
• What traffic will this generate, and in which direction? Your network owner will ask this, and the supplier should be able to answer it before the question is put.
• What happens if we switch it off? The correct answer for a monitoring system is nothing.
• Who owns the data, and how do we export it? Establish this before deployment, not when you want to change supplier.
• What will you hand over? A mapping document, the security design and the operational detail should be deliverables, not favours.

How we help

• Survey. What each system actually exposes, which data paths are realistic, and what the existing tags genuinely mean.
• Architecture. Where data is read, buffered and translated, and how the system behaves when any part is unavailable.
• Gateway hardware and firmware. Where off-the-shelf equipment does not suit. See embedded firmware development.
• Protocol implementation and translation. See industrial protocol integration.
• Boundary and security design. Segmentation, direction of flow, least privilege, and documentation your team can operate and defend.
• Upstream integration. Historian, maintenance system, MES and dashboards.
• Commissioning. Including deliberately causing the failures the design claims to handle.

The service page for this work is SCADA and PLC integration.

Historians and time-series databases

Where to store plant data has become a live question, because two quite different kinds of system now compete for the role.

Process historians are the established answer. They are built specifically for industrial data, integrate directly with SCADA systems, handle the compression described above, and come with tooling that process engineers already know. Their strengths are exactly that familiarity and integration. Their limitations tend to be licensing cost per tag, constrained analysis options compared with general-purpose tools, and difficulty getting data out into other systems.

Time-series databases from the wider software world are increasingly used alongside or instead. They handle high ingest rates, scale horizontally, integrate with general analysis and visualisation tooling, and are frequently open source. Their weaknesses are that they know nothing about industrial conventions, they do not integrate natively with SCADA, and somebody has to operate them.

In practice many sites end up with both, and that is a reasonable outcome provided it is deliberate: the historian remains the system of record for process data, trusted by the people who use it daily, while a time-series store holds higher-rate condition monitoring data and supports analysis that the historian is not suited to. The failure mode to avoid is two systems holding overlapping data with no agreement about which is authoritative, because that produces meetings in which two people present different numbers for the same question.

Whatever you choose, ask how data gets out before you put data in. A store that cannot readily export is a store that will constrain every future decision.

A sensible order of work

Integration projects benefit from sequencing that produces something usable early rather than attempting everything at once.

• Take what is easy first. Data already in a historian or SCADA system, reachable through an existing interface, gives you a working pipeline and a real result without touching controllers or adding hardware.
• Establish the boundary properly at that point, while the scope is small. Retrofitting segmentation onto a system that has grown organically is considerably harder.
• Add external sensing where nothing exists. This is where new hardware and installation effort arrive, and doing it after the pipeline works means one new variable rather than several.
• Integrate upstream. Into the maintenance system first, since that is usually where value is realised.
• Then extend. More assets, more measurements, more analysis, on an architecture that has already been proven at small scale.

The common alternative, specifying everything and building it in one project, tends to produce a long period with nothing working followed by an integration phase where every problem arrives simultaneously.

A short glossary

If you take one thing away

The technical work in plant integration is rarely the hard part. Reading a register, translating a protocol and storing a value are solved problems with mature tooling.

What decides these projects is whether the boundary was designed rather than improvised, whether the meaning of the data was established rather than assumed, whether timestamps and gaps were handled properly, and whether the people who own the systems were brought in early enough to say yes. Every one of those is cheap to get right at the start and expensive to correct once there is a year of data in a shape that turns out to be wrong.

Questions we are asked about this

Common questions

What clients ask before starting

Will reading from our PLC slow it down?

It can, if the request rate is high enough or the controller is already close to its limits. Serving data consumes scan time. The remedies are to rate-limit requests, to read from the SCADA system or historian instead, or to sense externally. This should be assessed rather than assumed either way.

Should we take data from the PLC or the SCADA system?

Usually the SCADA system or the historian where either exists, because they already aggregate and reading there adds no load to controllers. Go directly to the PLC when the value you need never reaches those systems, or when their interfaces are unavailable.

Is it safe to connect plant systems to the corporate network?

It can be, with a designed boundary: segmentation, a single controlled crossing point, and data flowing outward with nothing initiating a connection inward. It is not safe as a flat network, which is unfortunately how a good deal of it has been done historically.

Our PLC is twenty years old and cannot be patched. What do we do?

Accept that and protect it with the architecture instead. Segmentation, read-only access, strict control of what can reach it and monitoring of that boundary are the compensating controls. This is a recognised approach rather than a compromise, but it has to be deliberate.

Why do timestamps matter so much?

Because correlating events across systems is impossible if their clocks disagree. A gateway that timestamps on arrival rather than at source will misattribute the timing of anything that was buffered, which is exactly the data around an outage or a fault.

Can you write setpoints back from a dashboard?

Technically yes, and we advise against it unless there is a clear requirement. Writing into a control system is a different risk category from reading, and should have its own assessment, boundaries and testing rather than arriving as an extension of a monitoring project.

What if our documentation is wrong?

It usually is, at least partly. Tag lists and register maps are established by inspection and verified against values you can independently confirm, then recorded so the work is not repeated. Budget for this rather than assuming the documents are accurate.

Who needs to be involved from our side?

Whoever owns the control systems, whoever owns the networks, and whoever is responsible for production uptime. Integration touches all three, and projects that skip one of them tend to stall at exactly the point where that person has to approve something.

Start a conversation

What systems need to talk?

Tell us what controllers and software you run, what data you want to reach, and where it needs to end up. Network diagrams or tag lists speed this up considerably.

Leave empty

Your name *

Email address *

Company

Country *

What are you working on? * I agree that iTechGeeks may use these details to respond to my enquiry. Privacy policy. Send enquiry ↗

Prefer email? Write to info@itechgeeks.in