Industrial Data Integration: From Tag List to Acceptance

Technical guide by Arvin, METRAVON Instruments · Reviewed September 2026

Short answer

The difficult part of industrial integration is usually data meaning, not protocol conversion. Reading a Modbus register does not prove the value is usable. Every tag needs a physical meaning, engineering unit, data type, scaling, byte order, quality state, timestamp and read/write rule. Freeze this definition before selecting an RTU, protocol gateway or edge-computing device.

The tag list is the integration contract

A controlled tag list aligns the equipment supplier, controls team, integrator, platform developer and plant owner. It should identify the source device and channel or register as well as the business name displayed to operators. Changes to an address, range or unit need a revision record and an impact review.

Inventory devices and interfaces

Record each device model, firmware, electrical interface, protocol version, address, port settings and available documentation. Identify who owns the serial bus or network connection. Connecting multiple masters to one RS485 bus without a supported arbitration method can cause intermittent failures even when every device is configured correctly.

For existing PLC systems, first determine whether approved PLC data access can provide the required values without affecting the control scan or vendor support. Adding a second direct poller to field devices may create more risk than using the established controller interface.

Modbus details that must be explicit

• RTU or TCP transport, slave or unit identifier and serial port settings.
• Function code and whether addresses are documented as zero- or one-based references.
• Register quantity, data type, signed representation, byte and word order.
• Scale factor, offset, engineering unit and valid operating range.
• Exception responses, device-status registers and behavior during timeout.
• Polling interval, retry count and timeout that do not overload the device or bus.

Keep the raw value or frame available during commissioning. Correcting an unexplained value only in the dashboard hides the root cause and makes later systems inconsistent.

Choose the integration device from the task

Use remote I/O or an RTU when the main task is acquiring analog, digital or serial field signals. Use an industrial gateway when protocol conversion and platform connectivity dominate. Evaluate edge computing when the project genuinely requires local rules, filtering, aggregation, store-and-forward, multiple destinations or controlled application logic. Product categories overlap, so verify actual interfaces and resources.

Data quality, time and buffering

Transmit the original quality state and source timestamp where possible. Define how stale data is identified and whether a substituted value may be displayed. Synchronize clocks and document whether time is generated by the sensor, PLC, gateway or platform.

For outage buffering, calculate storage from tag count, sample interval, record size and required offline duration. Use a stable device identity and record key so retransmission is idempotent. Test chronological order, duplicates and the buffer-full policy during acceptance.

Write access and cybersecurity

Separate monitoring tags from writable commands. Every write should have a defined owner, authorization method, valid range, operating permissive, confirmation, timeout, result feedback and audit record. Remote write access must not bypass local control or safety logic.

Apply network segmentation, least privilege, unique credentials, controlled remote access, secure protocols where supported, configuration backups and documented firmware management. Do not expose field devices directly to the public internet.

Acceptance tests

1. Check each point or an agreed risk-based sample from source display to final platform.
2. Verify address, data type, sign, scale, unit, timestamp and quality state.
3. Force low, normal, high, invalid and out-of-range conditions where safe.
4. Disconnect a device and the WAN separately; confirm timeout, stale indication, buffering and recovery.
5. Test permitted writes, rejected writes, feedback, authorization and audit logs.
6. Restore a saved configuration to a spare or reset device and verify documented recovery.

Required project documents

Handover should include the device inventory, final tag list, register maps, network topology, port and firewall rules, configuration backups, account and role list, interface or API specification, test evidence, alarm ownership, change history and recovery procedure. A working dashboard without these records is not a maintainable integration.

Frequently asked questions

Does Modbus support guarantee integration?

No. You still need the transport, function codes, addresses, data formats, scaling and diagnostic behavior. The same protocol name does not mean two devices use the same register definition.

Who should own the tag list?

The equipment supplier defines source data, the integrator controls the unified technical list, and the process owner approves business names, units, limits and write permissions.

When is edge computing justified?

Use it for required local processing, filtering, buffering, rules or multiple destinations. For transparent conversion and a small data set, a standard gateway may be simpler and easier to maintain.

Why compare timestamps at every layer?

It distinguishes slow device sampling, gateway polling, upload delay and platform processing. Without timestamps, all latency is incorrectly blamed on the network.

Create a controlled signal and data dictionary

A tag name alone does not define a usable data point. The controlled dictionary should include source device, physical meaning, engineering unit, raw and scaled range, data type, byte order, update rate, timestamp source, quality rules, alarm use and read/write authority. Add valid minimum and maximum values where they can detect configuration errors. Assign an owner and revision to the dictionary so contractors do not maintain conflicting spreadsheets.

Use naming conventions that remain understandable across PLC, SCADA, historian and analytics systems. Preserve a stable identifier even if a display label changes. Document calculated values and their source tags; otherwise a volume, mass or consumption result can be mistaken for a direct measurement. For every command or setpoint, define permitted states, interlocks, confirmation and audit record.

Protocol details that commonly break integration

For Modbus, specify device address, function code, register reference, zero- or one-based addressing, integer or floating type, signedness, word order, byte order and scaling. A register list that omits one of these fields is incomplete. Verify representative negative, fractional, zero and high values on the real device. Do not accept a successful connection as proof that the numbers are correct.

For analogue loops, document whether 4–20 mA represents level, distance, volume or mass and how under-range and over-range currents are handled. For pulse and digital inputs, define edge, debounce, reset and rollover. For Ethernet protocols, agree namespaces, certificates, session limits and reconnect behaviour. Preserve vendor diagnostics where they help distinguish bad process data from lost communication.

Timestamp, quality and stale-data rules

Decide where the authoritative event time is created and how clocks are synchronized. A server arrival time is not the same as the time a remote RTU sampled the value. Carry the source timestamp through buffering and backfill. Define maximum age for each point and display stale data clearly instead of holding the last value without qualification.

Map device-specific faults into a shared quality model without discarding detail. At minimum distinguish valid, uncertain, bad, communication failure and maintenance override. Calculations must propagate quality: a total derived from one failed input should not remain marked good. Alarm logic should specify whether it acts on bad data, freezes, or enters a defined safe state.

Factory and site acceptance testing

Build a traceability matrix from every required signal to its test. In factory testing, simulate normal, minimum, maximum, fault and timeout states and verify scaling, units, text, alarms and permissions. In site testing, repeat critical points from the actual field device through the final screen or database. Capture screenshots or exported records together with test equipment references and software versions.

Interrupt each relevant network and power path. Confirm reconnect, buffer recovery, duplicate handling and current-data priority. Test prohibited writes as well as permitted commands. Reconcile a sample of historical records by timestamp and value after recovery. Record unresolved deviations with owner and due date; connection statistics alone are not acceptance evidence.

Versioning and operational support

Back up PLC, gateway, SCADA and mapping configurations as one approved release. Record firmware, library versions and checksums. A change to one register map can silently corrupt downstream data even when every system remains online, so use impact assessment and regression tests. Provide a rollback method and keep previous compatible configurations.

Monitor communication errors, data age, buffer use and rejected records after handover. Set thresholds that reveal gradual degradation before data is lost. Assign responsibility for field instruments, controls, network and platform, with a clear path for faults crossing those boundaries. Good integration is sustained governance, not a one-time protocol conversion.

Retain evidence.

Engineering note: Protocol access does not authorize process control. Writable integration requires approval from the equipment and process owners and a defined safe fallback.