Behind almost every integration between a field system and a cloud platform sits an unglamorous but critical artifact: a table that says this raw point over here corresponds to that named tag over there. It is the lookup that lets an integration translate a PLC register address into a meaningful tag name a person can read. This guide focuses on that mapping table itself - what it holds, who owns it, and how it slowly goes wrong when nobody tends it - rather than on the identity it produces or the one-time migration that builds it.
Cross-Reference Table in one line: A cross-reference table is a maintained lookup that maps each source system's tag or point identifier to the corresponding identifier in a target system - for example a raw PLC register address to a canonical cloud tag name. It is the living translation artifact an integration reads at runtime to know which source point feeds which target tag. Its value depends entirely on being kept accurate as devices, points, and naming change over time.
At its simplest, a cross-reference table is a set of rows, each pairing a source identifier with a target identifier. The source side might be a Modbus register number, a DNP3 index, an OPC UA node identifier, or a device-native tag string; the target side is usually the clean, canonical name a cloud SCADA or historian uses. But a useful table carries more than the two identifiers. It typically includes the site or device the point belongs to, a data type, an engineering unit, a scaling factor or conversion, and sometimes a description of what the point measures, so the mapping captures not just which name goes to which name but how the value should be interpreted on the way across.
The table is distinct from the identity it produces and from the migration that first populates it. A canonical tag name is the single authoritative name a measurement ends up with; the cross-reference table is the artifact that records how each raw source name is aliased to that canonical name. A tag-mapping migration is the project of building the initial mappings when moving from one system to another; the cross-reference table is what that project leaves behind and what the integration then relies on every day thereafter. In other words, the migration is an event, the canonical name is the result, and the cross-reference table is the durable, editable record that connects the two.
Because it is a data artifact rather than code, the table can live in many forms - a spreadsheet an engineer maintains, a database table an application queries, or a configuration file in a repository. The form matters less than the discipline around it. Whatever holds it, the integration treats it as the single authoritative answer to the question of which source point corresponds to which target tag.
A cross-reference table is only trustworthy if someone owns it and changes to it follow a process. Governance starts with clear ownership: a named person or team is responsible for the table, and additions or edits go through them rather than being made ad hoc by whoever happens to be configuring a device that day. Without that, two people can map the same source point to different target names, or reuse a target name for two different sources, and the integration quietly produces wrong data with no error to flag it. A governed table also records who changed what and when, so a mapping mistake can be traced and reverted.
Good governance ties the table to the systems it describes. When a new point is added on a PLC, the process that commissions it should also add a corresponding row, and when a point is decommissioned its row should be retired rather than left dangling. Ideally the table is version-controlled alongside other integration configuration, so a mapping change is reviewed like any other change and can be rolled back. Validation helps too: a simple check that every source point referenced by the integration exists in the table, and that no target name is claimed twice, catches a large share of mistakes before they reach production.
The reason this matters more than it seems is that the cross-reference table is a place where a small clerical error becomes a serious data error. A transposed register number or a mistyped tag name does not crash anything - it silently routes one well's pressure into another well's history, or scales a value by the wrong factor. Treating the table as governed, reviewed, authoritative data rather than a convenience file is what keeps those silent errors from accumulating.
The characteristic failure of a cross-reference table is not a dramatic break but slow drift. The physical world the table describes keeps changing - a PLC is reprogrammed and its register layout shifts, a device is swapped for a different model, a site is re-instrumented, or a point is repurposed to measure something new. If the table is not updated in step, its rows gradually stop matching reality. A row may still point at register 40012, but that register now holds a different measurement, so the integration keeps flowing data into the same target tag while the meaning underneath has changed. Nothing errors, but the data is wrong.
Stale entries take a few common forms. Orphaned rows map a target tag to a source point that no longer exists, so the tag goes stale or reads a default value. Duplicate rows map two sources to the same target, so values overwrite each other unpredictably. Drifted rows keep a valid-looking mapping whose underlying source has been redefined. Because none of these throw an obvious exception, they tend to surface indirectly - a dashboard shows a flatline, a report does not reconcile, or an operator notices a value that cannot be right. By then the mapping may have been wrong for weeks.
This is where a cloud SCADA helps keep the table honest. Merobix reads live from field devices, so a mapping that no longer corresponds to a real point shows up as data that stops updating, reports as bad quality, or falls outside expected bounds - signals an operator can act on rather than silent corruption. Pairing an authoritative mapping table with continuous monitoring of the tags it produces closes the loop: the table declares what each source should feed, and the live data reveals when a declaration has drifted out of date, so stale entries can be found and corrected before they poison the record.
A canonical tag name is the single authoritative identifier a measurement ends up with in the cloud SCADA or historian. A cross-reference table is the maintained artifact that records how each raw source identifier is aliased to that canonical name. The canonical name is the result you want, and the cross-reference table is the durable lookup that produces it and can be edited as things change.
Stale entries appear when the physical points a table describes change but the table does not follow. Reprogramming a PLC, swapping a device, re-instrumenting a site, or repurposing a point can all leave a mapping pointing at a source that no longer holds what the table claims. Because these mistakes rarely throw errors, they surface indirectly as flatlined dashboards or reports that fail to reconcile.
It can live as a spreadsheet, a database table, or a configuration file - the form matters less than the discipline around it. Whatever holds it, it should have a clear owner, follow a change process, and ideally be version-controlled so edits are reviewed and reversible. Storing it as governed, authoritative data rather than a convenience file is what prevents small clerical errors from becoming silent data errors.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.