SCADA Data Integration with addaNet

Buy a usable data path, from the source to a decision

A plant may already have a functioning SCADA system while production, maintenance and management still work from disconnected exports. The integration project begins with the report or action that is missing: a shift record, a pump operating history, a water balance or an exception sent to a responsible team. This makes it possible to choose a bounded point list and demonstrate value before extending the connection across the plant.

The operations owner defines what the record must explain. The OT or automation team identifies an approved source and protects the control environment. IT contributes network, identity and hosting requirements. We turn those inputs into a scope with named responsibilities and testable outputs. The project proposal should identify both the visible report and the engineering work needed to make its underlying data dependable.

Select the approved interface with the system owner

Existing SCADA servers, historians, gateways and instrument controllers can expose different interfaces depending on their configuration and licences. We review the actual system version, available connection, permitted reads and any supplier restrictions before choosing an approach. A familiar protocol name is only a starting point: supported data types, quality information, historical access and client limits all affect what can be delivered.

The selected path may use an approved OPC UA endpoint, a historian export, a supported messaging interface or a scoped gateway connection. For an existing Modbus interface, the register map, value representation and permitted polling behaviour are part of the engineering input. Where new wireless field measurements are required, LoRaWAN and 4G are assessed against the site conditions. These additions are specified separately from access to the existing control system.

Define the point list before building dashboards

Every point needs a source identifier, description, engineering unit, data type and destination name. Include the operating range, scaling, update expectation and the meaning of unavailable or invalid data. Discrete states deserve particular attention: a value of zero could mean stopped, healthy, closed or unknown depending on the source. The integration should preserve those meanings instead of assigning a convenient generic label.

Cumulative values require rules for rollover, reset and replacement. A new flow meter may restart at zero while the reporting period continues. If that event is treated as a negative consumption value, the dashboard can look plausible yet produce a wrong total. We agree how the replacement is recorded and how original readings remain accessible, so the reporting team can reproduce the calculation and explain any adjustment.

Establish access and control responsibilities

The first-stage scope identifies what is read, which account performs the access, and the approved route across network boundaries. Account privileges should match the required task. The OT owner approves any connection to the operational environment and the conditions under which it is tested. Network segmentation, access control and change management are established OT security practices described in NIST's 2023 Guide to Operational Technology Security.

A reporting project also needs practical operating rules. Decide who manages account expiry, certificates where used, network changes and supplier access. Confirm the route for disabling the integration and who can authorise re-enabling it. If a later phase includes control commands, define that phase's engineering, permissions, equipment feedback and protective functions explicitly. Local controllers and the site's approved interlocks remain responsible for their assigned real-time control tasks.

Give timestamps and data quality a clear meaning

A record can have a measurement time, a server time and an arrival time at the reporting platform. Those times can differ during an outage or a delayed import. We define which is used for trend alignment and period totals, and retain the information required to identify delayed records. Time-zone conversion, clock sources and the expected tolerance between relevant systems belong in the acceptance plan.

The interface should make stale, invalid and missing values visible. A flat trend during a broken connection should be distinguishable from a genuinely stable process. Likewise, a zero-flow reading and a period without flow data require different handling in a water balance. The reporting rule should say when a calculation is withheld or marked incomplete and which team reviews the underlying issue.

Agree what happens during a connection failure

The design identifies the source, gateway and reporting components that can store data, the conditions under which they continue operating, and the history that can be recovered. Storage availability depends on the selected equipment and configuration. We specify the intended retention, reconnect sequence and treatment of duplicates or records arriving out of order, then verify that behaviour using an approved test arrangement.

Recovery has two parts: restoring the current view and handling historical records. The project must distinguish a current operational alarm from a late record describing an event that has already ended. Agree how notifications behave during replay and how the user sees the affected period. These decisions prevent a successful technical reconnection from creating a confusing operational handover.

Separate factory checks from site acceptance

Factory acceptance testing verifies the integration against representative inputs before the live site connection. Site acceptance testing confirms the approved installation, actual sources, network route and user workflow. We prepare a test matrix that ties each requirement to an input, expected behaviour, observed result and responsible signatory. The companion SCADA integration FAT and SAT checklist provides a practical starting worksheet.

Tests should cover normal values, meaningful state transitions, invalid data, timestamps, retained history and the agreed recovery process. Failure scenarios are exercised through simulation or an isolated arrangement wherever a live test could disrupt operations. The site owner approves any operational test window. Unresolved items are recorded with an owner and an acceptance decision rather than disappearing behind a general statement that the dashboard works.

Make the handover useful to operations and IT

A handover pack should include the final point list, source-to-report mapping, configuration version, access responsibilities and acceptance results. Define how a new point, renamed asset or changed calculation is requested and approved. This gives the customer a controlled way to extend the system while retaining the meaning of historical records. It also makes a future support investigation more focused than starting again from screenshots.

Agree data exports, retention, user access and support arrangements as part of the project. A useful export contains identifiers, units and timestamps that make sense outside the original dashboard. If maintenance or finance will use the information in another application, include that destination in the acceptance example. The addaNet platform overview describes the wider monitoring and integration role.

Price the engineering work and continued operation separately

Initial costs depend on source systems, point types, interface licences, gateway requirements, network work, mapping complexity and the required reports. A collection of straightforward analogue values can be less demanding than a smaller set of counters and operational states with ambiguous meanings. Historical imports, custom business-system interfaces and access restrictions also affect the engineering effort and commissioning schedule.

Ongoing items can include platform services, connectivity, support and maintenance of the integration as source systems change. Identify which party owns each licence and what happens when an OEM upgrades the SCADA or historian. Ask for the assumptions behind the quotation, including the number of agreed interfaces and reports. This helps procurement compare scopes that deliver the same evidence, rather than comparing only gateway or subscription prices.

Start with a representative reporting problem

Choose a bounded use case with an available source, a named data owner and a practical acceptance method. For a pump operating history, the relevant records might be run state, fault state, flow and pressure. For a production report, they might include counts, product context and shift boundaries. Use a real operating task to decide which points belong in the first stage.

The first review needs a redacted point list, source-system details, the desired report, access constraints and the people who will approve the connection. Detailed network diagrams and credentials should be exchanged through the agreed project channel. Our IoT integration service covers the broader project delivery; the LoRaWAN-to-SCADA guide explains common architectural patterns when new field measurements also need to enter an existing SCADA.

Frequently asked questions

Technical reference

NIST SP 800-82 Revision 3: Guide to Operational Technology Security, September 2023 supports the OT access, segmentation and change-management considerations above. The project-specific point list, performance requirements and acceptance thresholds are agreed with the site's responsible team.

OPC Foundation, OPC UA Part 2 security model: threats provides additional context for reviewing unauthorised access, message handling and the effects on operational systems. Use the documentation for the actual configured interface during the project review.