Data Mapping

What is Data Mapping?

Technical definition

The work of defining how data elements in one system correspond to data elements in another – identities, attributes, units and meaning – so that information can be moved or integrated without losing its significance.

In brief

Data mapping is the translation table between your systems. Without it, every integration becomes guesswork and every report a manual investigation.

The Challenge

Systems do not speak the same language by themselves. A temperature can be called GT401 in the control system, Temp_Zone_A in SCADA and Room temperature in the energy reporting tool. Units differ, timestamps differ and the same equipment has different identities in different registers. When the mapping is missing – or only exists in one consultant’s head – every new integration becomes expensive, slow and fragile.

Mapping Comes in Many Forms

The term is used broadly, and in practice you will meet several related variants. All of them are parts of the same whole – a coherent technical information architecture:

Information mapping: The overall charting of what information exists in the organisation, where it is created and where it flows.

Technical data mapping: Field-level mapping of technical data between systems – signals, registers, attributes and units.

Asset information mapping: Connecting equipment identities and properties across registers, models and systems – so the pump in the BIM model is the same pump in the maintenance system.

Semantic mapping: Mapping meaning, not just format. Ensuring that “temperature” in one system really is the same quantity, unit and measuring point as “temp_C” in another.

Systems integration mapping: The specification of which systems exchange data, through which interfaces and with what responsibility.

Data and interface mapping: Combined mapping of data content and technical interfaces – APIs, protocols and file formats.

Lifecycle information mapping: How information follows the object and is handed over between phases – design, construction, commissioning, operations and maintenance.

HubMind’s Methodology

For us, mapping is part of the Map – and a deliverable in its own right, not a by-product of integration projects. We work with explicit, version-controlled mapping tables owned by the asset owner and maintained as a single source of truth.

The mapping is built on a shared naming convention, structured metadata and a well-designed UNS structure – so new systems connect to a known structure instead of every project inventing its own.

Warnings & Pitfalls

The one-off mapping: A mapping done once and then forgotten ages quickly. Systems are replaced, tags change and the table becomes fiction. Mapping is a maintained product.

Mapping hidden in integration code: When the translation only exists in a supplier’s script, it is neither reviewable nor reusable. Make it explicit, documented and version-controlled.

Format without semantics: Two fields having the same data type does not mean they mean the same thing. Without semantic mapping you are moving numbers, not information.