Most oil and gas facilities are not short on data — they are short on access to it. Compressor stations, tank batteries, and wellhead RTUs installed a decade or more ago are still running fine on the factory floor, quietly recording pressure, flow, and temperature every few seconds. The problem is that this data speaks Modbus, a protocol built in 1979, and it was never designed to hand information to an AI platform sitting three network hops away. Before any predictive model can see a single reading, someone has to build the bridge between that old PLC and the software making decisions on top of it, and Book a Demo to see how iFactory handles that bridge for you.
Give Your Oldest Field Devices a Direct Line to Modern AI
iFactory connects Modbus TCP and Modbus RTU equipment — PLCs, RTUs, flow computers, VFDs — into a live data layer that powers real-time monitoring and predictive maintenance without replacing a single controller.
Why Legacy PLC Data Stays Trapped in the Field
Modbus itself is not the obstacle — it is a simple, well-documented protocol that has survived four decades precisely because it is easy to implement. The obstacle is everything built around it: undocumented register maps, mismatched addressing conventions, and point-to-point connections that were never meant to feed a platform-wide system. These issues compound quietly until an integration project forces someone to confront them all at once.
None of this is a knock on Modbus as a protocol. It has outlasted far more sophisticated communication standards precisely because it asks so little of the devices that implement it, which is also why it ended up on nearly every generation of field equipment installed since the 1980s. The real cost shows up later, when a facility with fifteen or twenty years of accumulated equipment tries to unify all of it into one modern data layer and discovers that "speaks Modbus" was never the same thing as "documented, consistent, and ready to integrate."
Undocumented Register Maps
The technician who commissioned the PLC in 2011 knew which holding register held tank level. That knowledge rarely survives in writing, leaving every new integration to start with a guessing game against live equipment.
Inconsistent Addressing Conventions
One vendor's manual numbers registers from zero, another from one, and a third uses a five-digit prefix scheme. A single off-by-one error here silently returns the wrong value with no error thrown.
Fragile Point-to-Point Links
Serial RTU runs stretched across a facility, single-client TCP sockets that lock out every other system, and polling loops with no failover turn one loose connector into a full data blackout.
Understanding Modbus: What Your PLC Is Already Telling You
Every Modbus device organizes its data into four register types, and knowing which one holds what you need is the first real step of any integration project. Coils and discrete inputs carry single-bit values such as pump status or alarm flags. Holding registers and input registers carry 16-bit values such as pressure readings, flow totals, or setpoints. Getting this classification right before writing a single line of configuration prevents the majority of downstream errors.
Coils
Read/write single-bit values — pump run status, valve position, alarm acknowledgment. Accessed with function codes 01 and 05.
Discrete Inputs
Read-only single-bit values — limit switches, digital sensor states. Accessed with function code 02, cannot be written back.
Input Registers
Read-only 16-bit values — live analog readings such as flow rate or temperature. Accessed with function code 04.
Holding Registers
Read/write 16-bit values — setpoints, configuration parameters, calculated totals. Accessed with function codes 03, 06, and 16.
A Sample Register Map: What Real Mapping Work Looks Like
This is a simplified example of the kind of register map an integration team builds for a single flow computer before any polling begins. Real maps for a full facility can run into hundreds of rows across dozens of devices, which is exactly why manual spreadsheet tracking breaks down at scale.
| Register | Type | Data Format | Scaling | Description |
|---|---|---|---|---|
| 40001-40002 | Holding | 32-bit Float | x1 | Instantaneous Flow Rate |
| 40003-40004 | Holding | 32-bit Float | x1 | Daily Flow Total |
| 30005 | Input | 16-bit Integer | x0.1 | Line Pressure (psi) |
| 30006 | Input | 16-bit Integer | x0.1 | Process Temperature (°F) |
| 00001 | Coil | Boolean | - | Pump Run Status |
Notice that the flow rate and daily total each span two consecutive registers rather than one. Any value larger than a single 16-bit register — a 32-bit float or a 32-bit integer — has to be split across two addresses, and different manufacturers order those two halves differently. Some place the high word first and the low word second, others reverse it, and some go a step further and swap the byte order within each word as well. There is no universal standard here, which is exactly why live validation against a running device matters more than trusting the register map on its own. A value that looks reasonable but is actually built from the wrong byte order will still produce a number, just the wrong one, and that kind of silent error is far more costly than a connection that simply fails outright.
From Field Register to AI Platform: The Four-Stage Path
These four stages hold in roughly the same order regardless of how many devices are involved, whether the site has ten Modbus points or ten thousand — only the amount of documentation recovery work in stage one really changes with scale.
Device Discovery and Documentation Recovery
Every Modbus-capable device on the network is identified, along with its IP address or serial line, unit ID, and any surviving vendor documentation for its register layout.
Register Mapping and Data Type Validation
Each register is confirmed against live values, byte order and word order are checked for floats and 32-bit integers, and scaling factors are recorded so raw counts convert to engineering units correctly.
Polling Interval and Load Configuration
Read frequency is set per register based on how fast the underlying value actually changes, and requests are batched to stay well under the device's transaction-per-second ceiling.
Protocol Conversion and Continuous Validation
Converted data is published to the AI platform in a normalized format, with ongoing checks that flag stale values, dropped connections, or out-of-range readings before they reach a model.
Why a Shared Gateway Beats Direct Device-by-Device Polling
There are two ways to get Modbus data out of the field and into an AI platform. The first is direct polling, where every downstream system that needs data opens its own connection straight to the PLC or RTU. The second is a shared gateway layer that polls each device once, holds the current values in memory, and republishes them to as many downstream consumers as needed. Direct polling looks simpler on paper, but it runs into the same wall almost every time: older field devices were built with a small, fixed number of concurrent connections, often no more than six, and every additional system that tries to poll directly eats into that budget. Once the limit is hit, connections start failing silently, and troubleshooting becomes a guessing game about which system is holding the socket a given device needs.
A gateway architecture solves this by decoupling the field-side poll from the platform-side consumption. The gateway becomes the single source of truth for a device's current state, refreshed on the schedule that device can actually support, while your AI platform, historian, and SCADA screens all read from that shared layer instead of competing for the same limited connections. This also means a new consumer — a new dashboard, a new model, a new reporting tool — can be added without touching the PLC configuration at all, since it simply subscribes to data the gateway is already collecting.
A Common Scenario: The Missing Six Weeks of Data
A mid-size operator brought on a new production monitoring tool and pointed it directly at the same flow computers their SCADA system was already polling. Within days, both systems started reporting intermittent gaps — sometimes a full shift of missing readings with no error logged anywhere. The root cause was never a network fault; it was two systems fighting over a device that could only support so many simultaneous connections. Once a shared gateway layer was put in place to poll each flow computer once and serve both consumers from that single feed, the gaps stopped completely and neither team had to change how they used their own tools.
Who Owns a Modbus Integration Project
Controls or Instrumentation Engineer
Owns the register map itself — confirming which address holds which value, verifying scaling and data type, and signing off that mapped values match what the physical process is actually doing.
OT/IT Integration Lead
Owns the network path — IP addressing, VLAN segmentation, firewall rules, and making sure the gateway sits in a location that can reach every target device without opening unnecessary access into the control network.
Platform or Data Engineering Team
Owns what happens after conversion — how the normalized data is stored, tagged, and made available to dashboards and models, plus the validation rules that catch stale or out-of-range values before they reach a report.
Manual Point-to-Point Polling vs. a Unified Gateway Approach
| Factor | Manual Point-to-Point | Unified Gateway Approach |
|---|---|---|
| Client Connections per Device | Single client, often locked | Shared access for multiple systems |
| Register Documentation | Scattered across spreadsheets | Centralized, version-controlled map |
| New Device Onboarding | Days of manual configuration | Templated, hours not days |
| Fault Detection | Discovered after data goes missing | Flagged in real time at the source |
| Scalability Across Sites | Rebuilt per facility | Reusable configuration templates |
Stop Rebuilding the Same Integration at Every Site
iFactory's protocol conversion layer turns one-off Modbus integrations into a repeatable, documented process your team can trust across every facility.
Getting Polling Intervals Right: Too Fast Breaks the Network, Too Slow Breaks the Model
Polling interval is the setting most integration teams get wrong in both directions. Poll too aggressively and older serial-to-TCP gateways start dropping connections or returning stale cached values under load. Poll too conservatively and the AI platform is working from data that is already minutes old by the time an anomaly develops. The right interval depends on what the register actually represents, not a single blanket setting applied to the whole device.
Fast-Changing Values
Line pressure, flow rate, and vibration readings typically need a 1-5 second poll cycle to give predictive models enough resolution to catch early deviation.
Moderate-Change Values
Tank levels, temperature trends, and motor amperage usually hold steady enough that a 10-30 second cycle captures the trend without overloading the link.
Slow-Changing Values
Configuration parameters, calibration constants, and daily totals rarely need more than a 5-15 minute cycle, freeing up bandwidth for the readings that matter more.
Common Mistakes That Derail a Modbus Integration Project
Ignoring Byte and Word Order
A 32-bit float split across two registers can be read in four different byte-and-word orderings. Assuming the wrong one produces a number that looks plausible but is completely wrong.
Polling Every Register the Same Way
Treating a slow-moving configuration value the same as a fast-changing pressure reading wastes bandwidth and can push older gateways past their transaction limit.
Skipping Live Data Validation
Trusting a vendor's PDF register map without confirming values against a running device leaves outdated or incorrect documentation baked into the entire integration.
Single-Client Bottlenecks
Letting one system hold the only open connection to a device means every other tool that needs that data is either blocked or forced into a separate, conflicting poll cycle.
We had eleven flow computers on the pad, all Modbus, all with different register conventions from three different manufacturers. iFactory's team mapped every one of them and had live pressure and flow data feeding our dashboards inside three weeks — no rip and replace, no new hardware at the wellhead.
Frequently Asked Questions
Do we need to replace our existing PLCs to connect them to an AI platform?
No. If a PLC, RTU, or flow computer already speaks Modbus RTU or Modbus TCP, it can be integrated as-is through a protocol conversion layer that sits alongside your existing control system. There is no need to reprogram the PLC logic or swap hardware at the field level. Most facilities keep every original controller in place and simply add a gateway that reads the registers those controllers already expose. If you want a walkthrough of how this looks for your specific device mix, Book a Demo with our integration team.
How long does a typical Modbus register mapping project take?
For a single site with a handful of devices, register discovery and mapping usually takes one to two weeks, including live validation against running equipment. Larger multi-pad or multi-unit facilities with dozens of devices and inconsistent documentation can take three to six weeks. The timeline is driven almost entirely by how well-documented the existing register maps are, not by the complexity of the protocol itself.
What is the difference between Modbus RTU and Modbus TCP for our purposes?
Modbus RTU runs over serial connections such as RS-485 and is common on older field devices, while Modbus TCP runs over standard Ethernet and is used on newer equipment and network-connected gateways. Both use the same underlying register and function code structure, so a properly configured gateway can bridge RTU devices onto a TCP network without losing any data fidelity. Facilities frequently run both side by side, with a gateway handling the serial-to-Ethernet conversion in one place.
Can multiple systems poll the same Modbus device without conflicts?
Yes, but only if the integration is architected for it from the start. Many older devices only support a small number of simultaneous TCP connections, so a shared gateway layer that polls once and republishes the data to every downstream system prevents the connection limits and conflicting poll cycles that cause dropped data. This is one of the most common gaps our team finds when auditing an existing setup, and it is usually straightforward to resolve. Our support team can review your current architecture for exactly this issue.
What happens if a register value looks wrong after integration?
The most common causes are byte-order mismatches on multi-register values, an incorrect scaling factor, or an off-by-one addressing error between the documentation and the wire address. A properly built integration includes a validation step that compares polled values against a known reference reading before the data ever reaches a dashboard or model, which catches these issues immediately instead of weeks later when a report looks off.
Your Legacy PLCs Already Have the Data. Let's Put It to Work.
iFactory connects Modbus-based field devices to your AI platform with documented register maps, validated polling, and zero hardware replacement at the wellhead.
