Getting data out of the systems that already run your plant.

The integration is usually the expensive part

Most people approaching an industrial data project expect the sensors to be the cost. They rarely are. The larger and less predictable expense is connecting what you collect to the systems that already exist: the PLCs running the line, the SCADA package the operators watch, the historian the process engineers trust, and the maintenance and business systems where decisions actually get made.

That work is unglamorous, it is specific to your site, and it is where industrial data projects most often stall.

What is usually already there

• PLCs. Running the process, frequently holding useful data that nothing currently reads.
• SCADA or HMI. Supervision and operator interface, often with data that never leaves the screen.
• A historian. Recording process values, sometimes for years, sometimes at a resolution nobody has checked.
• Maintenance systems. Where work orders live, and where any condition-based alert eventually has to arrive to be useful.
• MES and ERP. Production orders, material movements and the numbers the business runs on.

The opportunity is rarely to replace these. It is to connect them, so that a reading from a machine can reach a decision without being retyped.

Read-only first, and usually read-only permanently

The control layer keeps production running, and the risk calculus around touching it is quite different from the risk of adding a dashboard. Our default is a read-only integration: we take data out, we do not write in. That removes any possibility of disturbing a control loop, and it makes approval from the people responsible for uptime far more straightforward.

Where writing back is genuinely required, it is treated as a separate decision with its own assessment, its own boundaries and its own testing, rather than as an extension of the monitoring scope.

How the connection is usually made

• Directly from the PLC, where it exposes an interface such as Modbus TCP, OPC UA or a vendor protocol, and where the controller has capacity to serve requests without affecting scan time.
• Through the SCADA system, where it already aggregates data and offers an interface, which avoids adding load to controllers.
• From the historian, which is often the easiest source for anything historical and the right one when you need context rather than live values.
• Externally, with added sensing, where the equipment offers nothing usable. See legacy machine retrofit.

Protocol selection sits inside this decision. Our article on OPC UA, MQTT and Modbus sets out how the options differ and when each is appropriate.

The OT and IT boundary

Operational technology and information technology have different priorities. OT values availability and determinism, and changes slowly for good reasons. IT values security, patching and central management. An integration crosses that line, which is why the boundary should be designed rather than improvised.

In practice that means network segmentation between the two, a defined direction of data flow, explicit rules about what may cross and what may not, and a clear position on whether anything from the IT side can ever reach the control network. Your site’s own policies constrain this, so they should be on the table at scoping rather than discovered during commissioning.

How we help

• Survey. Establishing what each system actually exposes, which is often different from what the documentation claims, and what the realistic data paths are.
• Architecture. Deciding where data is read, where it is buffered, where it is translated, and how the system behaves when any part of it is unavailable.
• Gateway hardware and firmware. Where off-the-shelf equipment does not suit the environment or the interface. See embedded firmware development.
• Protocol work. Implementation and translation between what the equipment speaks and what your upstream systems expect. See industrial protocol integration.
• Register and tag mapping. Establishing empirically what undocumented values contain, including scaling and word order, and recording it so it is not rediscovered.
• Upstream integration. Into historians, maintenance systems, dashboards and business software, so alerts become work orders rather than emails.
• Security design. Segmentation, least privilege, credential handling and a boundary your team can operate.

What we will not do

We will not modify safety-related control functions, and we will not place monitoring analysis in a position where a wrong value can cause harm. Safety systems, interlocks and protective functions have their own engineering discipline and approval requirements, and that boundary is drawn explicitly at the start of any engagement.

What you receive

The integration itself, documentation of every data path and mapping, the security and network design, and the operational detail a future engineer needs: what reads what, how often, what happens on failure, and where credentials live.