Industrial Data Modeling: From Raw Tags to Reusable Templates

DB12.DBD40 = 74.2 read from a PLC is a number. { "asset": "pump-01", "temperature": 74.2, "unit": "°C", "time": "2026-10-03T08:15:00Z" } is information. The difference between the two is data contextualization and modeling, and it is the difference between an analytics project staying at pilot and scaling.

Why raw tags are not enough

• There is no meaning: An address or tag name does not say what is measured, in what unit or which asset it belongs to.
• There is inconsistency: The same quantity has different names and scales on different lines.
• There is no reuse: Mappings made for one line are written again for another.
• Consumers carry the burden: Every analytics/BI/ML project interprets the data on its own.

What is an asset model?

An asset model defines which attributes a type of equipment provides: measurements, states, identifiers and their units. For example a “Pump” model could contain:

Pump
├── identity      (asset_no, location, manufacturer)
├── measurements
│   ├── temperature   (°C)
│   ├── vibration     (mm/s)
│   └── current       (A)
├── state         (running | stopped | fault)
└── counters      (run_hours)

The model is a template; each real pump (pump-01, pump-02 …) is an instance of it. Each instance maps its own source tags to the attributes in the template.

Benefits of template-based modeling

• Consistency: Hundreds of assets are published with the same structure and names.
• Speed: Adding a new asset is just creating an instance from the template and mapping its source tags.
• Change management: When an attribute is added to a template, all instances derived from it can be updated.
• Validation: Missing attributes or wrong types can be caught at the model level.

Contextualization: what to add to the model

1. Identity and location: Which asset, which line/site? (aligned with the ISA-95 hierarchy)
2. Unit and scale: Converting the raw value to an engineering value (for example 742 → 74.2 °C).
3. Timestamp: When the data was measured (it must be clear whether it is stamped at the source or at the collector).
4. Quality: Whether the value is trustworthy (good / uncertain / bad).
5. State and event context: Production context such as machine state, active product/recipe, shift.
6. Derived values: Calculated attributes such as averages or consumption per unit.

Publishing the model

Modeling alone is not enough; the model has to reach a consumer. The same model can be published over MQTT through a Unified Namespace, over REST/SQL, or to analytics platforms. The key principle: model once at the source, publish to many targets. That way there is no need to write separate transformation code for each target.

Applying it with HighByte Intelligence Hub

HighByte Intelligence Hub is a platform that applies this approach without code: asset models are built with reusable templates, nested attribute trees and model validation; data is conditioned with visual pipelines; and the result is published to MQTT/Sparkplug, REST, SQL and cloud targets. See the features page and the Industrial DataOps solution for details.

A checklist to get started

1. Pick the 1–2 most valuable equipment types (for example pumps, packaging machines).
2. For each type, define the needed attributes together with consumers (“who needs what?”).
3. Write down naming, unit and timestamp rules.
4. Apply the template on one line and validate with consumers.
5. Version the template; manage changes in a controlled way.
6. Replicate to other lines and plants with the template.